13:22 <Anderson-D> View management protocol is probably what I anticipate the most. River has already become my primary compositor and I'm really loving it.

13:23 <Anderson-D> Sway feels so bloated now

13:24 <Anderson-D> I would have probably stayed with sway if not the home-brewn config file formats, refusal to adapt new changes due to compat with i3, and confusing layouts

13:25 <Anderson-D> In these terms, awesomewm was probably the best wm I've ever used in terms of flexibility & customization, but it has (and will never have) no wayland support. River & config-files-as-scripts is the future :)

13:26 <Anderson-D> tl;dr: keep up the great work guys, river is awesome (no pun intended)

16:00 <snakedye> leon_p: thanks 👍

20:12 <dnkl> I'm having some issues with river's implementation of the foreign toplevel protocol

20:12 <dnkl> when an output is disabled, river sends out output_leave() events

20:12 <dnkl> but when the same output is re-enabled, no output_enter() events are fired

20:13 <dnkl> for reference, Sway doesn't seem to emit _any_ of those events (when an output is disabled/enabled)

20:13 <emersion> fwiw, sway seems wrong

20:14 <emersion> disabling an output removes the global

20:14 <emersion> which is an implicit leave

20:14 <dnkl> agreed, Sway's behavior doesn't really make sense. Just thought I'd mention it, in case someone is comparing behavior

20:26 <dnkl> https://github.com/riverwm/river/issues/487

20:27 <ifreund> dnkl: hmm, this is a nasty issue with how this protocol is designed

20:28 <ifreund> river does call the wlroots function to send enter events when an output is re-enabled, but it ends up being a no-op due to a race

20:29 <ifreund> it's very unlikely that the client will manage to bind the output global before river calls wlr_foreign_toplevel_handle_v1_output_enter()

20:29 <ifreund> not really sure what to do about this tbh

20:29 <dnkl> ifreund: ah, that's... annoying

20:31 <dnkl> I assume the same race exists at startup, unless the client defers binding the foreign toplevel interface until after all outputs have been bound?

20:31 <ifreund> yep that's right

20:31 <ifreund> which I've seen pretty much everyone trying to use the protocol hit

20:33 <dnkl> yeah, pretty sure yambar had this issue; looking at the code blue, we do defer binding the foreign interface

20:33 <dnkl> s/blue/now

20:34 <dnkl> sleep() - solves all problems 🙄

20:35 <ifreund> dnkl: actually, I'm going to call this a wlroots bug, wlroots solves this for wl_surface_enter() by listening for output bind in the surface code

20:35 <ifreund> the foreign toplevel management code should do the same

20:35 <ifreund> which would also get rid of the need to defer binding the interface on startup

20:36 <dnkl> that would be really nice

20:40 <ifreund> https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/1567

20:40 <ifreund> adding a comment there that the workaround doesn't work for the case you describe

21:03 <emersion> agreed

21:06 <dnkl> will do.

21:07 <dnkl> I'm guessing I can work around it by recreating the foreign manager every time a new output is created...

21:09 <ifreund> dnkl: I mean yeah, but I think it would be easier for you to patch wlroots :P

21:14 <dnkl> sure, but may want an interim solution...

21:16 <dnkl> I'll see if I can take a look, but I expect to be mostly offline over the holidays

21:17 <ifreund> no pressure of course, I think it should be a pretty straightforward fix though.

21:17 <ifreund> If nobody else has gotten to it by the time wlroots 0.16.0 is approaching I'll probably find time to do it myself

21:33 <dnkl> sounds like a great getting-into-wlroots-development issue :)

21:49 <emersion> it would be a reasonable candidate for a bugfix release