<leon-p>
I don't have time to look over it in detail today, but the proposed changes seem to be good
<leon-p>
what made you change your mind about river-options?
<ifreund>
It's I guess how stupidly inefficent the implementation was :D
<leon-p>
yeah
<leon-p>
that annoyed me too
<ifreund>
I spent a while trying to find a way to make it better, but then realized that there's no reason the compositor should be holding this state in the first place
<ifreund>
all it needs to do is pass it on to clients
<leon-p>
the inefficiency also made my main arguement against full window managers a bit hypocritical :D
<ifreund>
what argument was that?
<leon-p>
the amount of roundtrips needed for every action
<ifreund>
ah yeah, compare those two event sequences :D
<leon-p>
with a wm, you can have up to 7 steps of wayland communication happening between compositor, client and wm before anything happens on screen
yyp has quit [Quit: now it's safe to turn off your computer]
leon-p has quit [Remote host closed the connection]
snakedye has joined #river
<snakedye>
ifreund I understand correctly instead of checking events at an option handle, the "option" would be part of the layout event?