Run on Xwayland by default

[glitsj16]

Hi, I've been running Gnome-Pie (GP) for ages and love its functionality. But when running a GNOME Wayland session the application is somewhat crippled (as ~/.config/gnome-pie/gnome-pie.log kindly warns about). Several issues here mention/relate to this Wayland problem already. For fun I tried using GP on Xwayland, in an attempt to mitigate the known/documented shortcomings. I do realize this isn't fully futureproof, but IMHO the Xwayland backend isn't poised to disappear any time soon.

At first this didn't work, simply because the current code has GP running on Wayland by default. This is due to using a construct like:

GLib.Environment.get_variable("XDG_SESSION_TYPE") == "wayland"

throughout the codebase. When changing this to use the documented CLUTTER_BACKEND and GDK_BACKEND environment vars, things nicely fall into place and GP starts to shine again, as it should.

A crude, but working patchset to use GP on Xwayland by default can be found here. Please note these patches were made against 0.7.2. If there's interest to integrate this into GP, I'll be happy to help in preparing the needed PR's. All this shouldn't discourage devs to create a GNOME extension as proposed in #147, but it might be a nice workaround until such is ready.

[Schneegans]

This looks very promising, indeed. I did not know about this!

I guess that it is possible that GDK is compiled without the x11 backend. Do you know a possibility to check whether we're actually running on Xwayland after setting the GDK_BACKEND variable? If we're not, we would need to fallback to the current wayland "support".

Another question: Why do we need to set CLUTTER_BACKEND? Shouldn't GDK_BACKEND be sufficient?

As this is kind of an important contribution I suggest that you create a proper pull request and add yourself also to aboutWindow.vala and the AUTHORS file!

Thank you very much!

[glitsj16]

Do you know a possibility to check whether we're actually running on Xwayland after setting the GDK_BACKEND variable?

According to the documentation that should be possible: ... Since 3.10, this environment variable can contain a comma-separated list of backend names, which are tried in order. The list may also contain a '*', which means: try all remaining backends. The special value "help" can be used to make GDK print out a list of all available backends. For more information about selecting backends, see the gdk_display_manager_get() function. ... The aforementioned function is also documented in Vala here and here.

With these options available, I think we can make the code more robust and have proper fallbacks in place without much refactoring.

Another question: Why do we need to set CLUTTER_BACKEND? Shouldn't GDK_BACKEND be sufficient?

You're correct. I originally added CLUTTER_BACKEND because it was in the documentation I based this on. I've put together a second version of the patch-set which drops this particular environment var. It also introduces a new one, called GNOME_PIE_WAYLAND, which is used to determine what display server GP will run on. Basically it turns GP into running on X11/Xwayland by default and only uses Wayland when the user explicitly sets the GDK_BACKEND to 'wayland'.

I'll be doing PR's soon, just give me a few days to test things more thoroughly on Debian/Ubuntu too, as I developed and run this on Arch Linux for now. The coming week I can dedicate all the time it takes to tackle this and clean-up any crudely introduced code. Please feel free to comment, suggest alternatives etcetera.

[glitsj16]

@Simmesimme PR's are in. I made a name change in the environment variable to determine the wayland boolean throughout the code-base. It's now called GNOME_PIE_DISPLAY_SERVER, which can have 2 values: x11 or wayland. But the more important change is a new executable called gnome-pie-gdk-backend, which is used to check runtime availability of the x11 GDK backend. More info on that in the PR comments.

These are randomly picked names, so you can change these to whatever you feel is appropriate. Just make sure to update the files touched by this PR accordingly when you decide to change them.

Due to my lack of CMake experience I didn't integrate the newly introduced gnome-pie-gdk-backends executable. Obviously this will need to be taken care of.

[Schneegans]

I played around a bit (and fixed the window list group on Xwayland) and observed one issue:

Gnome-Pie seems to work on Xwayland only when another application which also runs on Xwayland has currently input focus. For example, it works when Firefox is in focus but doesn't when Nautilus is focused. Did I miss something or do you experience the same?

I am using Ubuntu 19.04 with vanilla Gnome Shell currently.

[glitsj16]

Gnome-Pie seems to work on Xwayland only when another application which also runs on Xwayland has currently input focus. For example, it works when Firefox is in focus but doesn't when Nautilus is focused. Did I miss something or do you experience the same?

I run Firefox with MOZ_ENABLE_WAYLAND=1 for security reasons and don't use nautilus that much, I prefer thunar for file management. Which is probably why I missed what you observe. I can confirm your observations.

After some trial and error, I did manage to get good results with Firefox on x11 and nautilus running on wayland by default. The only file needing additional changes was pieWindow.vala. Here's my diff:

@@ -128,7 +128,8 @@
         this.set_decorated(false);
         this.set_resizable(false);
         this.icon_name = "gnome-pie";
-        this.set_accept_focus(false);
+        this.set_accept_focus(true);
+        this.set_focus_on_map(true);
         this.app_paintable = true;

         // check for compositing

Please test the patch, I don't understand why it had this.set_accept_focus(false); to begin with, so there might be regressions changing that to true (although I didn't observe any). I added this.set_focus_on_map(true); for good measure.

[Schneegans]

Sadly, this does not change the behavior for me.

Still, when I run Gnome-Pie on Gnome Shell under Wayland, Gnome-Pie's hotkeys only work if certain applications have focus. I assume that those appliactions run on XWayland too - with MOZ_ENABLE_WAYLAND=1 I cannot open pies in Firefox anymore.

Also, when I move the mouse pointer to another location on the screen (without clicking, so the previously focused XWayland application keeps having the input focus), the pies open where my pointer left the XWayland application.

[glitsj16]

@Schneegans During the weekend I had some more time to delve into this focus/hotkey/mouse pointer issue. I removed all my GNOME tweaks/customizations to get as closely to your own setup as possible. First off, I can indeed replicate your latest findings. If my understanding of the issue is correct, we'll need to ensure there's always a focused Xwayland application window open prior to calling GP('s hotkeys).

I made a smallish proof-of-concept vala file that you can download here. After compilation (instructions inside) you'll need to place the resulting executable somewhere in your PATH for ease-of-use during testing. It should create a temporarily maximized, invisible yet focused Xwayland window to create the needed context for GP. Because it is maximized, the mouse pointer issues should be a thing of the past. Hotkey activation should work with this too. Over the weekend I noticed that keyboard shortcuts work just fine on Wayland windows when set up via gnome-control-center or dconf/gsettings with the help of an intermediate shell script, which you can find here. With both these files in place I was able to call GP's hotkeys on all windows, beit Wayland ones or X11 ones. There are some more comments inside this second file too and, like before, you'll need to ensure it's executable and accessible in your PATH during testing to keep things simple.

On a side-note, this routine also works for me in a gnome-shell extension I use called custom-hot-corners, so the user can call GP commands via pointer hotzones too if so desired. That's just a personal preference though, just a FYI.

As already hinted to above, if this works to your satisfaction, we'll need to integrate all this into GP (to avoid adding additional executables). I believe this is possible, for example by adding a command line option to run the invisible-but-focused Xwayland window prior to calling hotkeys. The shell script could be integrated via Posix.system calls and/or rewriting it as another vala file being part of GP. I haven't done this yet, just to avoid more mishaps and non-functioning PR's. Would be nice if you could test GP with these temporary files. Please feel free to ask if anything isn't clear or whatever you feel needs to be tackled.

[Schneegans]

I think we should wait with this some more. As the APIs evolve, there may be native possibilities on Wayland to achieve what we want without major hacks. For example, https://developer.gnome.org/clutter/unstable/ClutterInputDevice.html looks quite promising.