10:59 <ifreund> leon-p: I'm thinking your right, the most reasonable way to implement this is to leave it up to the client changing the setting

10:59 <ifreund> *you're

11:00 <ifreund> I'm thinking an arrange request in river-control taking a wl_output is what we want

11:18 <leon-p> Are you working on making riverctl a river-config client? If not I'd quickly do it today, since that be needed for going on with river-layout

11:27 <ifreund> Yeah that's my plan, I'll do that first to unblock you

11:29 <ifreund> looks like the layout PR just needs to be rebased onto master and have rivertile use river-options

11:29 <ifreund> and have the crashes mentioned in the comments fixed

11:32 <ifreund> whoops, forgot to use 2021 for the copyright headers in the river-options stuff

11:36 <betawaffle> ifreund: are you planning to get river into nixpkgs or nixpkgs-wayland?

11:36 <ifreund> betawaffle: I don't use nix so no, not personally

11:36 <betawaffle> k

11:37 <ifreund> would be happy to see it show up there though I won't be doing any packaging myself for void until a first relase

11:37 <ifreund> which will happen once we finish the in-progress massively breaking changes to river's custom protocols

12:13 <leon-p> wouldn't it make sense to wait with the first release at least a month, so that we'll notice if the protocols don't hold up to actual usage?

12:15 <ifreund> Yeah, not planning on doing the relase the second they are all merged

12:15 <ifreund> they are what's blocking the relase though

12:27 <ifreund> we're also blocked on the next wlroots relase as that fixes several crashes/bugs in river that are too complex/annoying to work around

13:42 <ifreund> leon-p: I think we need to state explicitly in river-option that the server may arbitrarily ignore any set_*_value request it likes

13:42 <ifreund> this is important if some options are only valid in certain ranges

13:42 <ifreund> or if the options are enum-like such as attach mode

14:57 <leon-p> Hmm... Wouldn't the layout situation be simplified if we allow marking options as "possibly layout affecting", so that river can start the layout request? I am just not too sure how I feel about clients tracking themselves what options should trigger a layout.

14:59 <leon-p> or maybe a layout could add a set of river-option handles it depends on...

15:01 <leon-p> both protocols are pretty solid themselves, just how to sanely connect them eludes me. The above idea is the best thing I came up with (and really not hard to implement, I think), but it is also not perfect...

15:04 <ifreund> leon-p: having the layout declare which options it depends on seems like the most robust solution so far

15:06 <ifreund> I should river-options properly implemented in riverctl in the next hour or two, got distracted by other things