04:00 <leon-p> ifreund: I think you river-option implementation may have an issue

04:00 <leon-p> basically, if an option for a wl_output is registered

04:00 <leon-p> and the then the output is destroyed

04:01 <leon-p> and recreated

04:01 <leon-p> the option will not match it anymore

04:11 <leon-p> wait... even if the same output is recreated, the wl_output will be different

04:11 <leon-p> so nevermind

04:12 <leon-p> although that does mean we should probably destroy options bound to an output if that output disappears, since they are nor reusable

04:12 <leon-p> s/nor/not/

08:59 <ifreund> Yes, I forgot to destroy associated options when river's internal Outputs are destroyed

08:59 <ifreund> will fix shortly

09:47 <ifreund> leon-p: https://github.com/ifreund/river/commit/cd005e15f8bcb6852b35fd3d89248e72611a5d5f

11:17 <cmoi11> Can I ask Questions regarding the code here?

11:18 <cmoi11> Or better open an Issue on Github?

11:21 <ifreund> cmoi11: code questions are best asked here, ask away

11:24 <cmoi11> Maybe it's more a question about XWayland. So in XwaylandView.zig in function handleMap is called whenever I open a new Xwayland window. In the function are the following lines:

11:25 <cmoi11> // Use the view's "natural" size as the default floating dimensions

11:25 <cmoi11> view.float_box.width = self.xwayland_surface.width;

11:25 <cmoi11> view.float_box.height = self.xwayland_surface.height;

11:26 <cmoi11> So the question:

11:28 <cmoi11> Where does this 'natural size' come from? Because the floating Popups in Steam are are drawn with this size and they are far too small

11:28 <cmoi11> I think they should have size from the X size hints maybe.

11:29 <ifreund> probably, yeah. I only made xwayland work well enough to be able to use the few programs I use

11:29 <ifreund> patches welcome

11:31 <cmoi11> Alright. I open a pull request with my suggestion and we'll discuss from there?

11:32 <ifreund> well, Ideally you should test to see if it works first :P

11:32 <cmoi11> Yeah sure I test it on my machine first :)

11:35 <leon-p> for reference, on X there are multiple different size hints. Most of them are totally redundant, but for some unholy reason they are all used by different programs. Not sure how wlroots exposes this, but I am not surprised we use the wrong size for some X windows.

11:36 <ifreund> there's a wlr_xwayland_surface_size_hints struct we can examine

11:40 <ifreund> I think the real problem here is that we aren't listening for request_configure currently

11:41 <ifreund> we should probably just need to send a configure to xwayland views that are floating with the dimensions they request

11:50 <cmoi11> Maybe in XwaylandView.zig pub fn needsConfigure check if the size_hints are indicating the window should float?

11:51 <cmoi11> And then do this in pub fn configure

11:52 <ifreund> no, that stuff is related to river's atomic transaction system

11:53 <ifreund> you need to add a listener for wlr.XwaylandSurface.event.request_configure which we don't handle at all currently

15:57 <cmoi112> ifreud: I have a simple patch ready that solves the Xwayland floating size issue in steam that I described above. Are you interested or do you prefer a solution with the request listener you mentioned above?

15:58 <cmoi112> ifreund: Sorry for the typo in your name!

16:02 <ifreund> Feel free to open any PRs that you think make river better, I've already given you (and everyone else) permission to do that by having the repo up on github :D

16:02 <ifreund> the worst thing that can happen is that I find some issue and choose not to merge it

16:30 <cmoi112> Alright :)

19:44 <cmoi112> Would it be possible to implement cycling through a set of layouts? Probably difficult because river is not aware of the layouts... What do you guys think?

19:52 <ifreund> I think that's best implemented in "userland" once river's control protocols are more flexible

20:53 <ifreund> you could actually implement that in userland right now

20:54 <ifreund> though it would be probably be annoying to make it work nicely with multiple outputs

21:11 <cmoi112> By userland you mean with riverctl, right?

21:11 <cmoi112> Or in the init file?

21:30 <ifreund> Yeah riverctl or any other wayland client that speaks the protocols required

21:30 <ifreund> the init file is nothing more than an arbitrary executable, nothing special about it

21:46 <cmoi112> Does river "know" its currently used layout? So that something like "riverctl get current_layout" is possible?

21:47 <ifreund> it does, but it isn't exposed by riverctl currently

21:48 <ifreund> to implement something like this currently you'd need to keep track of the current layout separately. This could be done using the new river-options protocol

21:48 <ifreund> see riverctl get/set/declare-option

21:48 <ifreund> s/separately/manually/

21:49 <cmoi112> Ok cool, I'll check it out!