07:38 <ifreund> I think I finally came up with some more concise names for update_windowing_* and update_rendering_* that I'm happy with

07:38 <ifreund> renaming them to update_* and render_* actually works out pretty nicely IMO

07:39 <ifreund> I think it's fine to keep the "windowing state" and "rendering state" terminology in the protocol docs, I just think "windowing" is such an awkward word to have all over the codebase of a window manager

07:40 <ifreund> it becomes natural to have an update() function and a render() function in the window mananger rather than needing to use the much more awkward update_windowing() and update_rendering()

07:41 <ifreund> and river-internal naming should clean up a lot as well.

07:57 <ifreund> hmm, now thinking about using manage() rather than update() to be a bit less generic

07:58 <ifreund> (totally not motivated by the fact that there's a core library function called update in janet that would conflict :D)

07:58 <ifreund> manage seems like the right verb for what a window manager should do though I must say

07:58 <ifreund> it manages and it renders

10:42 <leon-p> I can manage with the changes you've rendered upon us

12:34 <zuki> how do I get which output the cursor is currently on in rwm?

12:36 <leon-p> I don't think there currently is a wayy

12:36 <leon-p> a few cursor related things are still missing right now

12:37 <leon-p> f.e. there also isn't a way to tell which area of the window an interaction happened, so rivers current multi-directional resize can't be implemented by a WM right now

13:07 <ifreund> alright, I finished my renaming spree and pushed it

13:09 <ifreund> zuki: We could definitely add a river_seat_v1.pointer_enter_output event or similar

13:10 <zuki> that would be perfect for my use case of "focusing" outputs to pick which output new windows get assigned to.

13:12 <leon-p> that will be a rewarding weekend of catching up with protocol churn, eventually

20:21 <pkap> ifreund: i made another PR for zig-wlroots. I translated everything that's in the wlroots header files. Now I'm wondering if this is the correct approach or if I should restrain it to the things we actually need in river...

20:22 <pkap> Could remove some stuff again.

20:38 <ifreund> pkap: binding everything is fine, will get you some reviews when I have time :)

20:47 <pkap> Alright. Wlroots exposes so much stuff, but in the implementation, apparently it's enough to initialize two structs.

20:48 <pkap> Feels a bit weird :D