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/
_whitelogger has joined #river
_whitelogger has joined #river
waleee-cl has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #river
_whitelogger has joined #river
travankor has joined #river
<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
<ifreund> *you're
<ifreund> I'm thinking an arrange request in river-control taking a wl_output is what we want
<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
<ifreund> Yeah that's my plan, I'll do that first to unblock you
<ifreund> looks like the layout PR just needs to be rebased onto master and have rivertile use river-options
<ifreund> and have the crashes mentioned in the comments fixed
<ifreund> whoops, forgot to use 2021 for the copyright headers in the river-options stuff
<betawaffle> ifreund: are you planning to get river into nixpkgs or nixpkgs-wayland?
<ifreund> betawaffle: I don't use nix so no, not personally
<betawaffle> k
<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
<ifreund> which will happen once we finish the in-progress massively breaking changes to river's custom protocols
<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?
<ifreund> Yeah, not planning on doing the relase the second they are all merged
<ifreund> they are what's blocking the relase though
<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
<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
<ifreund> this is important if some options are only valid in certain ranges
<ifreund> or if the options are enum-like such as attach mode
ifreund1 has joined #river
ifreund has quit [Disconnected by services]
ifreund1 is now known as ifreund
travankor has quit [Remote host closed the connection]
<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.
<leon-p> or maybe a layout could add a set of river-option handles it depends on...
<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...
<ifreund> leon-p: having the layout declare which options it depends on seems like the most robust solution so far
<ifreund> I should river-options properly implemented in riverctl in the next hour or two, got distracted by other things
waleee-cl has joined #river
jjanzic has joined #river
fsdfdsf has joined #river
fsdfdsf has quit [Client Quit]
travankor has joined #river
travankor has quit [*.net *.split]
travankor has joined #river
travankor has quit [Remote host closed the connection]