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]
maringuu has quit [Ping timeout: 250 seconds]
maringuu has joined #river
waleee-cl has quit [Quit: Connection closed for inactivity]
waleee-cl has joined #river
yyp has joined #river
gspe has joined #river
leon-p has joined #river
yyp has quit [Ping timeout: 260 seconds]
yyp has joined #river
yyp has quit [Quit: now it's safe to turn off your computer]
yyp has joined #river
gspe has quit [Quit: gspe]
gspe has joined #river
yyp has quit [Quit: now it's safe to turn off your computer]
yyp has joined #river
anthony25 has quit [Quit: Quitte]
anthony25 has joined #river
snakedye has joined #river
<snakedye> If I send a layout request to river for each of my outputs, does river sends back an event to both output even if only one of those output's layout needs to be updated?
Bonicgamer[m] has joined #river
yyp has quit [Quit: now it's safe to turn off your computer]
<leon-p> it shouldn't
<leon-p> or better said, if your layout is "active" (which basically means it was the last one used and hasn't since been destroyed) then river trusts the layout generators judgement
<leon-p> if you send river the paramters changed event, river will start a new layout demand, if your layout is active of course
v0idify has left #river ["Leaving"]
<leon-p> we do it this way to a) allow layouts to seemlessly depend on external parameters and b) to avoid having to track which layout depends on what river-option (I tried implementing it and it was pretty annoying)
<leon-p> snakedye: ^
<leon-p> snakedye: by the way, I investigated the other issue we talked about before
<leon-p> when changing the tags, river first sends the layout demand, then the output_status update
<leon-p> but it is possible to have your layout to depend on the currently focused tag
<leon-p> you just need to issue the parameters_changed request, like you would when an option changes.
<leon-p> this isn't ideal of course, because it means one layout demand is wasted and clients have to do a ton of unecessary configures, but it works
<leon-p> we might want to improve this in the future though, as layouts depending on the focused tag is a feature I had mind when I designed the protocol
<snakedye> I did this but yeah it isn't really efficient and you can see the views being adjusted when you focus the tag
<leon-p> yeah, it is not great, but it is a functional workaround
<leon-p> I might fix it later, but I do not know when
<leon-p> ifreund: your input on this? Do you think the order of the output_status update and the layout_demand can be swapped when focusing tags without messing anything up?
<ifreund> hmm, that would mean that you'd see your status bar update its UI for the currently focused tags before the transaction completes if the transaction takes more than one frame
<ifreund> add a "probably" there, it'd be very timing dependant and racy
<leon-p> I am pretty sure most status bars would be out of sync anyway, wouldn't they? Considering they render to a buffer and commit _after_ the transaction is done.
<leon-p> swaybar on sway definitely is a frame late
<ifreund> probably, though I don't notice any bad frames with waybar currently
<ifreund> maybe telling them about the tag change early would improve the average case, I don't known
<ifreund> s/known/know/
gspe has quit [Quit: gspe]
snakedye has quit [Ping timeout: 240 seconds]