20:18 <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?

20:42 <leon-p> it shouldn't

20:43 <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

20:44 <leon-p> if you send river the paramters changed event, river will start a new layout demand, if your layout is active of course

20:46 <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)

20:49 <leon-p> snakedye: ^

21:07 <leon-p> snakedye: by the way, I investigated the other issue we talked about before

21:08 <leon-p> when changing the tags, river first sends the layout demand, then the output_status update

21:09 <leon-p> but it is possible to have your layout to depend on the currently focused tag

21:09 <leon-p> you just need to issue the parameters_changed request, like you would when an option changes.

21:10 <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

21:11 <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

21:11 <snakedye> I did this but yeah it isn't really efficient and you can see the views being adjusted when you focus the tag

21:12 <leon-p> yeah, it is not great, but it is a functional workaround

21:12 <leon-p> I might fix it later, but I do not know when

21:13 <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?

21:20 <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

21:20 <ifreund> add a "probably" there, it'd be very timing dependant and racy

21:22 <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.

21:22 <leon-p> swaybar on sway definitely is a frame late

21:23 <ifreund> probably, though I don't notice any bad frames with waybar currently

21:23 <ifreund> maybe telling them about the tag change early would improve the average case, I don't known

21:23 <ifreund> s/known/know/