Improve multi-monitor handling under wayland #1276
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When a monitor gets disconnected, the destroy event of all associated windows gets called, and the window gets removed.
This PR changes that behavior: the window is still closed but the configuration is kept using the existing reload mechanism. In addition, a callback is added to listen for new monitors, triggering a reload when a new monitor gets connected.
This logic also reloads already running windows, which has a positive and negative effect:
I also had to work around an issue: the monitor model is not yet available immediately when a new monitor callback triggers. Waiting in the callback does not help (I tried 10 seconds). However, waiting outside, it always became available after 10ms.
Tested with a dual monitor setup under KDE through a combinations of:
In all these cases the behavior is as expected, and the widget gets loaded on the first available monitor (or stays unloaded until one becomes available).
It also works when opening a window without any of the configured monitors being available.
There is one remaining error from GTK when closing the window:
GLib-GObject-CRITICAL **: 20:06:05.912: ../gobject/gsignal.c:2684: instance '0x55a4ab4be2d0' has no handler with id '136'
.This comes from the
self.gtk_window.disconnect(handler_id)
call. To prevent that we'd have to resetdestroy_event_handler_id
.I have not tested under X11, and I'm not sure if the behavior should be the same there.
Fixes #1158
Checklist
Please make sure you can check all the boxes that apply to this PR.
docs/content/main
directory has been adjusted to reflect my changes.cargo fmt
to automatically format all code before committing