00:15 <gbrlsnchs> sewn: I was a total noob when it came to Wayland, so that book helped me with understanding the basics, specially about requests and events

00:17 <gbrlsnchs> then, yes, after understanding how the client communicates with the display server, reading the protocol files made a lot more sense 🙂

15:30 <leon-p> pkap: did you leave out the identifier event on purpose in your implementation of ext-foreign-toplevel-list? I missed this in my initial review and apparently it is legal to leave it out (although I may to fix lswt to work with that)

15:39 <Beer> Is any updates about release of river 4.0?

15:48 <leon-p> are there any specific features you are interested in? Because they may already be in a release. Unless it's the WM protocol, in which case I'll advise patience

16:02 <leon-p> ifreund: are we still on the same page w.r.t. linking wl_seat and river_seat_v1? Because I am about to add features to my WM which require seats.

16:02 <leon-p> And I think it makes sense to link wl_output and river_output_v1 as well TBH

16:07 <ifreund> leon-p: in theory yes, the details of how best to do so need to be worked out though to avoid races and awkward edge case states

16:09 <ifreund> Ive also been thinking about the output side of things recently, we definitely need access to the identifying information wl_output provides for things like restoring windows to a removed/readded output

16:10 <ifreund> however, the plan was for there not necessarily to be a 1-to-1 correlation between river outputs and wl_outputs...

16:10 <ifreund> tldr; needs design work

16:12 <ifreund> leon-p: RE the identifier event, I had assumed wlroots sent it, I missed that too I guess

16:14 <ifreund> leon-p: uh, pretty sure the wlroots code is meant to send it automatically?

16:14 <leon-p> does it? I somehow had in my mind that this was left up to the compositor, but to be fair someone took over that wlroots PR from me

16:15 <leon-p> I'd generally prefer a 1-to-1 mapping between river objects and corresponding wayland objects because it would make the API I expose to users a lot cleaner

16:16 <leon-p> especially w.r.t. when I add support for other protocols as well

16:23 <leon-p> anyway, I can work on a few other things before I do things that require wl_seat and wl_output for now, but eventually this will be a blocker for me probably

16:42 <ifreund> leon-p: the point of non 1-to-1 mapping for outputs is to support stuff like mirroring or tiled displays (2+ wl_outputs map to 1 river_output)

16:43 <ifreund> though its also not entirely clear if it makes sense to expose multiple wl_outputs or not in those cases

17:55 <leon-p> I see, and I think we talked about that before...

17:55 <leon-p> FWIW it's definitely less annoying to not have a 1-to-1 mapping for outputs