* fix: improve multi-monitor handling under wayland
When a monitor gets disconnected, the destroy event of all associated
windows gets called, and the window gets removed.
This patch 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:
- positive: if currently running e.g. on the second monitor specified in
the list, the window can get moved to the first monitor
- negative: if reloading starts it on the same monitor, it gets reset
(e.g. graphs)
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:
- enabling/disabling individual monitors
- switching between monitors
- specifying a specific monitor in the yuck config
- specifying a list of specific monitors in the yuck config
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 reset `destroy_event_handler_id`.
* fix: do not call gtk::main_iteration_do while waiting for monitor model
Executors that poll a future cannot be called recursively (in this case
glib::main_context_futures::TaskSource::poll).
So we cannot call gtk::main_iteration_do here, which in some cases led to
the future being polled again, which raised a panic in the form of:
thread 'main' panicked at glib/src/main_context_futures.rs:238:56:
called `Result::unwrap()` on an `Err` value: EnterError
We can just remove it as tokio::time::sleep() ensures the main thread
continues to process (gtk) events during that time.
0e409d4a52