ifreund changed the topic of #river to: river - a dynamic tiling wayland compositor - https://github.com/ifreund/river - channel logs: https://freenode.irclog.whitequark.org/river/
leon-p has quit [Quit: leaving]
leon-p has joined #river
waleee-cl has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #river
gspe has joined #river
yyp has joined #river
yyp has quit [Ping timeout: 246 seconds]
yyp has joined #river
yypnc has joined #river
yypnc has quit [Remote host closed the connection]
pkill9 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
travankor has quit [Remote host closed the connection]
travankor has joined #river
<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
<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
<emersion> what are you trying to do?
<ifreund> emersion: river allows setting some options per output with "riverctl set-option -output HDMI-A-1 foobar 42" for example
<emersion> what kind of options?
<ifreund> stuff like the layout to use, padding between views, etc
<emersion> ok
<emersion> kanshi doesn't seem like a good solution to this
<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
<ifreund> yeah I agree, I think kanshi isn't a great fit here
gspe has quit [Read error: Connection reset by peer]
<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
pkill9 has joined #river
<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
<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 :)
<leon-p> yeah, it makes more and more sense to use some sort os session manager :D
<leon-p> s/os/of
<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
<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
<ifreund> that would be one way to solve this yeah
<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
<leon-p> that would require keeping track of whether the default options have been changed.
<leon-p> i think not modify existing outputs options is fine though
<leon-p> like, if you change an option called `default_whatever`, would you expect the current state to be affected or the future state?
<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
<leon-p> true. although I kind of expected that when we decided to have default options
<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
<leon-p> that would make sense
<leon-p> but does not really work for options designed to be per-output
<leon-p> instead, why don't we have globale `default_*` options, and whenever an output is created, create the corresponding per-output options`
<leon-p> also: is the config executed before the first outputs are created? If not, this is not worth considering any further.
gspe has joined #river
<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
<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
yyp has quit [Read error: Connection reset by peer]
gspe has quit [Quit: gspe]
gspe has joined #river
<ifreund> yeah I got that, I'd just rather find a clean way that doesn't require hardcoding if possible
yyp has joined #river
yyp has quit [Client Quit]
yyp has joined #river
<leon-p> that would not require hardcoding, would it? The user could define their own `default_*` options in the init
<ifreund> oh I see, magic strings feel icky though
<leon-p> yeah true
<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.
<leon-p> I'd just need to modify rivertile to handle the case of the options not existing, but thats trivial
<ifreund> agreed
<ifreund> leon-p: just rebased the river-layout branch onto master so it has riverctl mod-option
<leon-p> just as I wanted to push the rivertile modifications. now I have to rebase too :D
<ifreund> sorry :/
<leon-p> nah, it's fine
<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
<leon-p> yeah that was a great addition
<leon-p> pushed the commit. rivertile will now set the options it depends on to some sane defaults when they are unset
<ifreund> cool, I'll have to think about how best to solve this option situation
<ifreund> I haven't run into any issues with the new layout functionality of the branch though through normal usage
<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
<leon-p> i suspect most edge cases to be related to connecting and disconnecting layout clients.
<leon-p> like what happend when a client disappears in the middle of a layout demand?
<leon-p> although I think I got the obvious ones by re-arranging one disconnect and connect.
snakedye has joined #river
snakedye has quit [Quit: Connection closed]
snakedye has joined #river
<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) {`.
snakedye has quit [Quit: Connection closed]
waleee-cl has joined #river
snakedye has joined #river
snakedye has quit [Quit: Connection closed]
snakedye has joined #river
<ifreund> snakedye: that function is generated from the protocol xml
<ifreund> look at zig-cache/zig-wayland/river_layout_unstable_v1_client.zig
<ifreund> see also river-layout-unstable-v1.xml
snakedye has quit [Ping timeout: 240 seconds]
leon-p has quit [Ping timeout: 240 seconds]
leon-p has joined #river
gspe has quit [Quit: gspe]
gspe has joined #river
yyp has quit [Quit: disconnected]
leon-p has quit [Quit: leaving]
pkill9 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
pkill9 has joined #river
gspe has quit [Quit: gspe]
snakedye has joined #river