Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve multi-monitor handling under wayland #1276

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

bkueng
Copy link

@bkueng bkueng commented Jan 25, 2025

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:

  • 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.

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.

  • All widgets I've added are correctly documented.
  • I added my changes to CHANGELOG.md, if appropriate.
  • The documentation in the docs/content/main directory has been adjusted to reflect my changes.
  • I used cargo fmt to automatically format all code before committing

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`.
@elkowar
Copy link
Owner

elkowar commented Feb 5, 2025

I'm down to merge this once someone has tested if the behavior breaks anything under X11, once the conficts are resolved ^^

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[BUG] Crash when monitor turned off
2 participants