waleee-cl has quit [Quit: Connection closed for inactivity]
exception has joined #river
travankor has joined #river
travankor has quit [Remote host closed the connection]
travankor has joined #river
trav47882 has joined #river
travankor has quit [Ping timeout: 240 seconds]
trav47882 is now known as travankor
travankor has quit [Ping timeout: 240 seconds]
_whitelogger has joined #river
leon-p has joined #river
_whitelogger has quit [Ping timeout: 260 seconds]
_whitelogger_ has joined #river
waleee-cl has joined #river
<leon-p>
huh, I think at first using river-layout won't be "every frame is perfect". For example, when a change in the layer shell triggeres output.arrangeViews(). At some point we should probably guard transactions in certain places so that they don't happen when a layout is doing its thing, but I'd like to do that in a follow up PR.
ifreund1 is now known as ifreund
exception has quit [Quit: rip internet]
exception has joined #river
<ifreund>
leon-p: should we state in the protocol that clients only need to reply to the most recent layout_demand? That would probably simplify the logic on both ends
<ifreund>
also say that the server will ignore responses to an old layout_demand after sending a new one
<ifreund>
and no worries if you don't get the transactions working perfectly before asking for a review, I can probably be helpful with direction there
<leon-p>
I wouldn't say "only respond to the newest one", I'd just include that responding to a layout demand is not necessary
<leon-p>
That older ones may get ignored is implied IMO
<ifreund>
sounds good, similar wording is used for xdg-shell's ack_configure