12:26 <leon-p> just removed the main view concept and the layout name from river-layout

12:26 <leon-p> But if we want clients to monitor their configuration values through river-config, there needs to be a way for them to request a layout demand

14:27 <ifreund> leon-p: indeed, do you think that's a better fit for a new request in river-layout or for a river-control request?

14:58 <ifreund> leon-p: I think a river-layout request on the zriver_layout_v1 object would be fine

15:40 <leon-p> I'd prefer this to be in river-control tbh.

15:41 <leon-p> but I think acting on a river-layout-v1 object makes more sense, so that the server can easily check if a new layout is actually needed

15:47 <ifreund> leon-p: the way I see it, we will probably need to arrange views after most river-control actions already, and unconditionally on the commit request if queuing actions

15:47 <ifreund> a separate request that does nothing but ask for an output to be re-arranged would be kinda weird I feel

16:45 <ifreund> oh shit, this looks worth examining: https://gitlab.com/kirbykevinson/libinput-config

16:46 <ifreund> rather hacky though :D

16:50 <leon-p> yeah, I just added a request for that in the protocol, but then realized that its not a good approach: even with rivertile we already have four layouts per output. If now the main-amount or something changes, each of them will issue a layout.markDirty(), which causes river to check for each if they are the currently active layout.

16:50 <leon-p> Lot's of wasted cycles. Not a fan

16:51 <leon-p> however, re-arranging the views on every river-config operation is also not ideal IMO, since I was kinda planning on ab^H^Husing it for non-layout related values

16:51 <leon-p> Needs more thought

18:37 <leon-p> actually, why don't we make full use of the command-queuing and put the burden of checking whether the output needs to be re-arranged on the client changing the setting?

18:37 <leon-p> So queue up a change to some value and then a layout.

18:47 <ifreund> I'm not sure I trust clients enough for that

18:48 <ifreund> they'll either be lazy and cause unecessary transactions or forget to trigger one when one is needed

18:48 <ifreund> I need to spend some time to think on this, I'm going to try and finish up the river-options PR real quick first though

19:38 <ifreund> alright, river-options works with the example client I just wrote

19:38 <ifreund> I think I'll probably just merge it like this, implementation in riverctl and migration of options can come later

21:47 <leon-p> cool, I'll rebase and port river-layout