00:45 <Anderson-D> leon-p: thank you!

04:36 <neeasade> hello all. is contrib/layout.py the most-straightforward place to start messing with layout clients? it appears so, but wanted to check

04:45 <neeasade> and, if I understand correctly, it just goes through all the windows and assigns dimensions -- is there a way to get current information about a view before doing things

08:37 <novakane> weird I can't make the tests run in zig-wlroots next-zig branch

08:37 <novakane> `zig-cache/zig-wayland/drm_client.zig:52:97: error: use of undeclared identifier 'Buffer'`

08:45 <Anderson-D> neeasade: what sort of info do you need? I think you can fetch some via river-status protocol. https://git.sr.ht/~leon_plickat/stacktile might be great (and easy to read) as an example for your layout provider.

15:16 <ifreund> novakane: not sure, passes for me

15:24 <novakane> ifreund: oh, that's weird because it's not really related to zig 0.9 maybe I messed up deps branch

15:36 <novakane> anyway that was just to update the build.zig file, so I guess you did it now

15:58 <elshize> is there a tool that would allow me to run some cmd on an output connect? say, like kanshi, but something that would allow me to run an arbitrary command? in particular, my yambar exits every time I disconnect a display (I switch it between my work and home computers) and would like to start it when it reconnects (yambar doesn't seem to support this)

15:59 <elshize> I can always bind some key to a script that kills all bars and starts them again, but it would be nice for it to work automatically

16:09 <emersion> kanshi allows you to run any command, iirc

16:09 <elshize> emersion: oh, I didn't know, I'll look it up

16:11 <elshize> emersion: ok, you're right, it's right there in the manual; I just assumed it was for outputs only, didn't even think to check, my bad; thanks!

16:11 <emersion> np :)

16:14 <dnkl> elshize: there's an open issue on yambar about this. I agree it would be nice to get this fixed...

16:15 <emersion> ah, didn't realize it was for working around a bug

16:16 <emersion> yeah, instead of spending time trying to work around the bugs, it's better to spend time fixing them :)

16:26 <dnkl> if we fix this in yambar, we can also do things like hide/show the bar (through e.g a key binding)

16:54 <elshize> dnkl: yes, I saw that issue. sadly, I'm way out of my depths here. I'd love to learn some wayland at some point, but i'm quite busy at the moment :/

16:57 <dnkl> elshize: I'll probably get to it, sooner or later (probably later...). I'm not affected by it, so my reasons for fixing this is mainly to enable other features that needs to be able to have the bar

16:57 <dnkl> bar's surface destroyed

17:23 <elshize> dnkl: that's fair; I'll just work around it for now.

23:10 <ifreund> new draft of the lock screen protocol I've been working on: https://github.com/riverwm/river/blob/river-lock/protocol/river-lock-v1.xml

23:11 <ifreund> probably going to send this upstream to wayland-protocols as ext-lock-v1 tomorrow but I plan to implement this in river in the next few weeks cause wayland protocols moves sloooow

23:17 <emersion> we totally don't take multiple years to merge stuff

23:17 <ifreund> xD

23:40 <leon-p> ifreund: what sparked your interested to work on a lockscreen protocol?

23:50 <leon-p> ifreund: protocol freedback: How is focusing handled? When there are multiple outputs, and therefore multiple lock surfaces, which one will receive keyboard events? This is probably compositor policy, but that should probably be noted.

23:51 <leon-p> what happens to the cursor? Is it hidden, like right now with swaylock, or shown, like the Big Desktops™ do?

23:53 <emersion> cursor should be up to the client, just like regular clients, see wl_pointer.set_cursor

23:55 <leon-p> does swaylock hide the cursor? TBH I always just assumed it was some specific server-side magic, but it makes sense in hindsight