-
-
Notifications
You must be signed in to change notification settings - Fork 40
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
widgets: fall back to Xwayland #234
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #234 +/- ##
=======================================
Coverage 93.17% 93.17%
=======================================
Files 58 58
Lines 11051 11051
=======================================
Hits 10297 10297
Misses 754 754 ☔ View full report in Codecov by Sentry. |
This doesn't seem to work. For some reason it still connects to Wayland anyway. It does it when I set |
Defaulting to |
OpenQA test summaryComplete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2025010617-4.3&flavor=pull-requests Test run included the following:
New failures, excluding unstableCompared to: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2024111705-4.3&flavor=update
Failed tests15 failures
Fixed failuresCompared to: https://openqa.qubes-os.org/tests/119126#dependencies 3 fixed
Unstable tests
|
Is it necessary for clicking outside the menu to close the menu, or is it good enough to require clicking again on the widget? The latter might be fixable in the menu itself, by closing the menu when the widget is clicked. |
9dee5a2
to
18901a0
Compare
It is necessary, it is a dom0 widget, it should not have the bad behavior of the vm widgets (which also should work better wrt to closing, but that's out of scope here). |
Can you try my most recent commit? That dismisses the menu when it loses focus. |
I don't think this addresses the root cause, which is some wayland failure - this works correctly under X and so, from what you said previously, should work correctly under XWayland. I don't think we want to patch the whole world, if it requires additional workarounds like this (which BTW duplicate what the menu generally does on its own) I don't think this is a good solution. |
5d08789
to
d48cfae
Compare
d48cfae
to
b8abcd6
Compare
pylint complains a lot, and also rpm fails to build (%files not updated) |
fb35583
to
d5b17b0
Compare
d5b17b0
to
e011e5f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally looks good, one question - have you tested it on multi-monitor setup? No idea if it would work/not work, but X11 can be weird about multiple monitors.
There is an issue with this... when a widget's menu is open, the mouse cursor disappears (as soon as you move it). It seems to "work", as you can click on things, stuff gets selected when you hover over them etc, but you don't see the actual mouse cursor... I think an earlier version of this PR didn't have this issue, but I'm not 100% sure. As for multi-monitor, seems to work fine, menu closes when you click on the other screen too. |
This has two parts: 1. Set GDK_BACKEND=x11, so that GDK3 chooses to use X11 as its backend. This must be done while only one thread is running, as otherwise undefined behavior results. It also must be done before gi.overrides.Gdk is imported, as otherwise it will be too late to set the GDK backend. Therefore, this code is run very early, and RuntimeError is raised if the preconditions are violated. 2. Create a fullscreen invisible window for mouse input. This works around Xwayland not passing all pointer input to X11. The menu is dismissed if the user clicks on the fullscreen window. This hack is only used if WAYLAND_DISPLAY is set.
e011e5f
to
e12308e
Compare
Can you make sure your repository is clean before doing the build? There might be a problem due to the build directory being unclean. In any case, the commit I just pushed works on my machine.
👍 |
I doubt it was unclean repository, but could be some miss-merge. Anyway, with the latest commit it is a bit better. Now the cursor is visible, but has "X" shape, instead of an arrow... |
I’ll ask on KDE chats about that. |
It looks similar to the default X11 cursor shape when you get plain Xorg
without any application running. Maybe you need to set some to get the
normal arrow? But I'd expect GTK to do that for you...
…--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
|
I suspect this is a GTK bug. I will try |
The widgets do not work under Wayland, so just use Xwayland for now.
If GTK somehow still connects to Wayland despite WAYLAND_DISPLAY being unset I will not be happy.
This is broken under KDE because of a bug in KDE (https://bugs.kde.org/show_bug.cgi?id=468085), but that can be fixed.