09:43 <ifreund> leon-p: actually, I don't think I'll need generational indexes or anything fancy for wayland object lifetime management

09:44 <ifreund> it's impossible to "deep copy" abstract types in janet unless the C/Zig code implementing the abstract type provides a deep copy function

09:44 <ifreund> which I won't of course

09:45 <ifreund> and that means that I can simply have a nullable pointer to the wayland object from each value of the abstract wl_proxy type and store a pointer to the single janet abstract value in the wayland object's userdata

09:46 <ifreund> if the janet value is GC'd before the wayland object is destroyed, I'll just leak the wayland object

09:46 <ifreund> if the wayland object is destroyed first, I'll set the pointer stored in the janet value to null and error if it is used

09:47 <ifreund> Unrelated, but I think the janet implementation of a wayland scanner can literally just be a single macro :D

09:48 <ifreund> the only tricky part will be handling the wl_interface structs that need to be generated

09:52 <ifreund> I think I'll end up generating them dynamically at runtime the first time they are needed and never freeing them

09:53 <ifreund> libwayland doesn't really care if the wl_interfae pointer it gets passed is a static global or some random malloc'd buffer I have filled with the correct data

09:53 <ifreund> having a scripting language that can speak arbitrary wayland protocols without the need for any kind of build step seem like it would be really nice

09:57 <ifreund> anyhow, I've saved some notes on this stuff but probably won't get around to actually implementing things for a while

09:57 <ifreund> the path forward is now clear in my head though :)

12:17 <leon-p> looking forward to whatever you end up doing

12:18 <leon-p> I have been thinking since yesterday, and wondering about dropping the C API. If you could pass lists between zig and scheme, in both directions, a lot of possibilities would open up

12:19 <leon-p> mostly optimizations. If (visible-windows output) is implemented in zig rather than scheme, I can avoid all but one key check

12:23 <leon-p> same for (first-visible-window), which could then as an optional argument either take an output or a list of windows to check

20:47 <zuki> is there a way of getting the currently active monitor in riverwm from a shell script?

23:43 <kaizo> i personally use river-bedload and jq for these kinds of things so the command id use with those would be "river-bedload -print outputs | jq '.[] | select (.focused==true) | .name'"