waleee-cl has quit [Quit: Connection closed for inactivity]
gspe has joined #river
<leon-p>
hmm... turns out having layouts depend on options is kinda complex
mmurd has quit [Ping timeout: 260 seconds]
<leon-p>
all my attempts at implementing that are kinda messy
<leon-p>
so I have a different approach in mind:
mmurd has joined #river
<leon-p>
instead of layout declaring options as dependencies, there could be a parameters_changed request
<leon-p>
layouts can raise it if their parameters, including options and external stuff, changed.
<leon-p>
the server will ignore all of these requests except for the one coming from the last used layouts
<leon-p>
This approach has the drawback that all layouts per output wake up and respond to options changing if they all depend on it, but I think this is not a big deal as 1) the server implementation is significantly simplified, 2) there will probably not be many layout clients running at once.
<ifreund>
leon-p: that sounds reasonable and a lot simpler
<leon-p>
I want to get river-layout done for real this week-end, so I could use your help with the transaction.
<leon-p>
I think I already explained it, but I can't block commitTransaction when a layout demand is in progress, because then river will crash when a view is destroyed.
<ifreund>
Is making transactions per-output something that would help if I implemented that today?
<ifreund>
ah yeah, the code handling destruction is a little ugly, it probably needs to be slightly reconsidered
<leon-p>
no idea, tbh. I have not yet have the time to attempt to grok the transaction system.
<ifreund>
my sense is that it would make the code a bit cleaner and more efficient if there are in fact multiple outputs in use, but wouldn't really allow anything that isn't already possible
<ifreund>
I'll probably wait until river-layout is merged to avoid conflicts
<leon-p>
ok, then I'll get back to you once I have done all the non-transaction things