riverwm
restore views to evacuated outputs on reconnect
implements #666
untested, will test tomorrow when I am back at my desk.
(should have waited for #999 to be the next number, but oh well)
Thank you for this, it seems to work as expected. Views are on the correct output after reconnecting.
I am trying out your layout generator (Stacktile). Is it also possible to restore on reconnect things like the number of primary views, or the width ratio between primary and secondary views?
My outputs or maybe my GPU trigger a reconnect every time they come out of standby, so I would need to go back and adjust these manually for each tag every time after stepping away from my PC and coming back.
@Leon-Plickat Is there any reason this is a draft aside from the lack of testing? Also, it looks like it needs a rebase.
Is this change still on track for a merge? One small issue that remains is that the order of the restored views are not always preserved.
I assume you tested it? Nice, so I won't need to dig out my second screen.
Window order depends on what you do with the windows on their new output. I don't think previous window order can be restored easily.
Also, I think if the user explicitly modifies windows (i.e. resizing, moving, order) I think we actually should make the new output their native output and not restore those windows to re-connected outputs.
I assume you tested it? Nice, so I won't need to dig out my second screen.
Yes, happy to report it has been working great for me for the last few months.
Also, I think if the user explicitly modifies windows (i.e. resizing, moving, order) I think we actually should make the new output their native output and not restore those windows to re-connected outputs.
I think that's a reasonable approach.
Also, I think if the user explicitly modifies windows (i.e. resizing, moving, order) I think we actually should make the new output their native output and not restore those windows to re-connected outputs.
This makes me a bit worried about where exactly to draw the line here and how easy it will be to forget to clear the remembered output in one of these cases in code. I think prioritizing predictability and code simplicity might be the same thing here.
On Mon Mar 11, 2024 at 10:59 AM CET, Isaac Freund wrote:
I think prioritizing predictability and code simplicity might be the same thing here.
I am not sure this applies to all cases.
F.e. a user might disconnect an external screen from a laptop and then continues to use the windows evacuated from that output for a while, resizes them, moves them to different tags, changes view order, etc. Then a few hours later they reconnect to the same screen or maybe even a different one.
The current code will move the windows "back" to that output, but that may not be what the user expected.
As a regular user I'd definitely expect the views to get back to the second screen when reconnected. But if I were to modify the view by moving, resizing or spawning a new window, I'd expect it to not be sent back to the second monitor (specially after few hours as mentioned), because I'd probably have modified my layout to a new workflow by then. This covers the scenario in which some monitors outright disable themselves and the OS loses the display output entirely. This sometimes happens even during a signal interference.
F.e. a user might disconnect an external screen from a laptop and then continues to use the windows evacuated from that output for a while, resizes them, moves them to different tags, changes view order, etc. Then a few hours later they reconnect to the same screen or maybe even a different one.
To be clear, I agree with you that it would be better to forget about a stored output when a user manually interacts with a window. My concern is how that behavior can be implemented in a robust and predictable way.
Perhaps we can only forget the previous output on float-toggle, fullscreen-toggle, resize, move and tag changes. Those are the only operations where it's clear that they are explicit. For window order changes it gets more muddy, since changing the order for one window changes it for adjacent ones as well. We could forget the output in the command handler, but I think it's better to just stick with the unambiguous options I listed above.
I think we can post-pone that discussion until someone actually complains and just merge this code as-is for now.