05:36 <leon-p> figured out why I pointer operations were funky for me: I totally missed that the delta is from the start of the operation

06:46 <ifreund> leon-p: indeed, this happens to solve a lot of issues that arise when timeouts happen

06:48 <ifreund> this is also what fixes resize with absolute pointer events (e.g. when using the wayland Backend)

06:48 <ifreund> https://codeberg.org/river/river/issues/1261

07:54 <leon-p> currently investigating how to display a list of hidden and ocluded windows. I am wondering whether it makes sense for river itself ot implement a hidden surface removal algorithm and send a river_window_v1.ocluded event. River already has the z-coords, which a WM otherwise would need to track manually.

07:57 <ifreund> leon-p: the scene graph kinda does that already, but iirc it's at scene node granularity so not quite what you want

07:57 <ifreund> I'm not sure if it makes sense to expose that in the protocol, I'm definitely not going to work on that before this initial PR is merged

07:59 <ifreund> also the scene stuff is a pure optimization and can be disabled with an environment variable

08:01 <ifreund> looks like it would require this wlroots PR to make the information available to river: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4735

08:03 <ifreund> It would also be nice to use scene visibility info for idle-inhibit stuff

08:08 <leon-p> I was mostly thinking about the window switcher menu thing I want to implement grouping windows which are not explicitly hidden but occluded somehow first

08:09 <leon-p> I can live without that for now though, worst case I just start keeping track of z ordering

10:02 <leon-p> just reintroduced pointer based resize and move after the protocol change and it's hard to overstate how much nicer such code is to write in scheme than a compiled language

10:02 <leon-p> https://gitlab.gwdg.de/leonhenrik.plickat/antares/-/commit/2678fec1cfe4f6c3d7a362aefca26fcdc678c102

10:08 <ifreund> nice

10:08 <ifreund> I think I'm currently on track to have a window manager I can daily drive in ~500 lines of janet

10:09 <ifreund> I think the distinction is mostly high level/low level rather than compiled/interpreted though fwiw

10:09 <ifreund> also one can compile and optimize scheme code just fine :P

10:09 <leon-p> yeah, actually the scheme code /is/ compiled, so s/compiled/high-level/

10:09 <ifreund> abstraction does in fact make it easier to express things concisely

10:10 <ifreund> you just lose some control over how exactly things happen

10:10 <leon-p> and I see we aim for different ends of the feature-count spectrum :D

10:10 <ifreund> leon-p: this is just my first WM :D

10:11 <ifreund> I'll write another one eventually that is more different from river 0.3.x and more ambitious

10:11 <ifreund> this one isn't going to need text rendering or anything complicated though

14:51 <pkap> Can rwm window managers work with wlr-layer-shell?

14:55 <ifreund> pkap: not yet, I ripped out layer shell support on the rwm branch cause it got in my way

14:56 <ifreund> Ideally I think window managers should provide their own shell UI with river shell surfaces

14:57 <ifreund> realistically, I'll allow them to enable layer shell at some point.

15:09 <pkap> Great that this is planned. I think this will block me from switching over soon because I make heavy use of waybar and fuzzel.

15:10 <pkap> But long term all features of current river will be available for rwm window managers?

15:11 <pkap> Or are there other things which will not be possible with river-rwm?

15:24 <ifreund> pkap: I expect that everything river 0.3.x does will be possible for a window manager to do by the 0.4.0 release

15:25 <ifreund> though Im not motivated to write a wm that clones river 0.3.x behavior myself

16:28 <leon-p> aside from things like input configuration, focusing solely on window management I think the only thing missing to emulate current river is that the WM knowing where a window was interacted with so it can adjust reisze direction accordingly

16:42 <ifreund> Not sure if focus-follows-cursor always can be done yet

19:16 <pkap> Awesome. I'm happy then. I don't need focus follows cursor. It's unintuitive anyway.

19:20 <pkap> leon-p: with resize direction do you mean distinguishing between making a windows larger or smaller?

23:11 <leon-p> pkap: I mean which edge of the windows remain stationary