10:43 <ifreund> hmm, unless I'm missing something kanshi can't be used to set arbitrary default options for all new outputs with the current state of river and kanshi

10:44 <ifreund> kanshi's output directives can use "*" to match all outputs, but there doesn't seem to be a way to acces the names of the outputs matched in order to run commands targeting them in an exec directive

10:50 <emersion> what are you trying to do?

10:51 <ifreund> emersion: river allows setting some options per output with "riverctl set-option -output HDMI-A-1 foobar 42" for example

10:52 <emersion> what kind of options?

10:52 <ifreund> stuff like the layout to use, padding between views, etc

10:52 <emersion> ok

10:53 <emersion> kanshi doesn't seem like a good solution to this

10:54 <ifreund> perhaps river should gain a new feature to define default options for new outputs, but since this is already solveable outside of the compositor I'd prefer not to make the compositor or the protocol used for options more complex

10:54 <ifreund> yeah I agree, I think kanshi isn't a great fit here

11:55 <leon-p> ifreund: is there an ETA for the river-layout merge? I was thinking about starting to move the configuration to river-options, but thaat would depend on the changes you pushed to the PR

11:59 <ifreund> hmm, I'm not sure I want to merge it before we have a good solution for setting default options for all new outputs. Right now it's definitely higher friction to use than master

12:00 <ifreund> I ported my config over to it yesterday though and finally got a per river session runsvdir set up to manage rivertile, waybar, foot --server etc :)

12:01 <leon-p> yeah, it makes more and more sense to use some sort os session manager :D

12:01 <leon-p> s/os/of

12:02 <ifreund> I think I'm going to merge the pointer constraints PR in the next hour or so, then rebase river-layout on to master and see if I can't figure out a good way to handle this per-output config

12:03 <leon-p> could we perhaps have global options which get copied when output options get created? That would be the solution with the least user-facing fricion

12:04 <ifreund> that would be one way to solve this yeah

12:05 <ifreund> perhaps also a good way, though then we should probably consider whether or not changing the global option should change the per output options if they haven't ever been explicitly set

12:06 <leon-p> that would require keeping track of whether the default options have been changed.

12:06 <leon-p> i think not modify existing outputs options is fine though

12:08 <leon-p> like, if you change an option called `default_whatever`, would you expect the current state to be affected or the future state?

12:09 <ifreund> there's one problem with that approach, and that is that it only works for the select few options we hardcode in river, not for arbitrary options users may define

12:10 <leon-p> true. although I kind of expected that when we decided to have default options

12:10 <ifreund> if there was an implicit rule that if a per-output option has not been defined but a gloabal option with the same name has been defined instead the gloabl should be transparently used, this would work for arbitrary user defined options as well

12:11 <leon-p> that would make sense

12:11 <leon-p> but does not really work for options designed to be per-output

12:12 <leon-p> instead, why don't we have globale `default_*` options, and whenever an output is created, create the corresponding per-output options`

12:13 <leon-p> also: is the config executed before the first outputs are created? If not, this is not worth considering any further.

12:37 <ifreund> leon-p: Yeah I think so, but I don't want to specify all outputs manually. I want my same config to work for WL-1/WL-2 in nested sessions and for HDMI-A-1 normally and for whatever my laptop's screen is called

13:14 <leon-p> ifreund: I wasn't talking about having a default_* option per-output, but rather one globally. Like have a global `default_foo` option and then every newly created output gets a `foo` output-specific option with the same value

13:18 <ifreund> yeah I got that, I'd just rather find a clean way that doesn't require hardcoding if possible

13:36 <leon-p> that would not require hardcoding, would it? The user could define their own `default_*` options in the init

13:36 <ifreund> oh I see, magic strings feel icky though

13:37 <leon-p> yeah true

13:37 <leon-p> although whatever we do, I think it may be a nice idea to have no per-output default options other than the layout namespace.

13:38 <leon-p> I'd just need to modify rivertile to handle the case of the options not existing, but thats trivial

13:40 <ifreund> agreed

13:51 <ifreund> leon-p: just rebased the river-layout branch onto master so it has riverctl mod-option

13:52 <leon-p> just as I wanted to push the rivertile modifications. now I have to rebase too :D

13:52 <ifreund> sorry :/

13:53 <leon-p> nah, it's fine

14:01 <ifreund> I'm liking the decision to allow silently overwriting existing mappings. Simply editing rerunning the init script works pretty well to edit the config while river is runnning

14:01 <leon-p> yeah that was a great addition

14:03 <leon-p> pushed the commit. rivertile will now set the options it depends on to some sane defaults when they are unset

14:09 <ifreund> cool, I'll have to think about how best to solve this option situation

14:10 <ifreund> I haven't run into any issues with the new layout functionality of the branch though through normal usage

14:11 <ifreund> probably should try and find edge cases with wleird's slow-ack-configure and the 'footclient sh -c exit' thing that caused issues in the past

14:17 <leon-p> i suspect most edge cases to be related to connecting and disconnecting layout clients.

14:18 <leon-p> like what happend when a client disappears in the middle of a layout demand?

14:18 <leon-p> although I think I got the obvious ones by re-arranging one disconnect and connect.

15:08 <snakedye> ifreund Could you explain this line in rivertiler `if (self.output.top.layout) |layout| layout.parametersChanged();` ? I looked the rest of the code and `parametersChanged` doesn't appear anywhere else than in that if statement `if (self.value != .unset) {`.

16:07 <ifreund> snakedye: that function is generated from the protocol xml

16:07 <ifreund> look at zig-cache/zig-wayland/river_layout_unstable_v1_client.zig

16:09 <ifreund> see also river-layout-unstable-v1.xml