GDK_BACKEND=x11GDK_BACKEND is being inherited by spawned applications.
This is undesirable as many applications do support wayland and I would prefer to only use x11 for ulauncher itself as a workaround.
Ulauncher version: 4.3.2.r8
Linux distro: Arch
Desktop environment: SwayWM
Nothing interesting
This also has unwanted side effects like searches opening a new (x11) instance of Firefox instead of using the already open (wayland) instance of Firefox
If you close Ulauncher and open it from the terminal env GDK_BACKEND=x11 shouldn't be set I think (meaning apps shouldn't use Xwayland). This breaks keyboard binding though, but maybe you can add it this way.
So basically run pkill ulauncher; ulauncher -v, then try to open an app. Does it open in XWayland or normally?
If this works, you could override GDK_BACKEND by copying /usr/share/applications/ulauncher.desktop to ~/.local/share/applications/ and removing env GDK_BACKEND=x11. If you have Ulauncher set up to autostart, then you also need to remove it from ~/.config/autostart/ulauncher.desktop.
@friday that solution may not work because Ulauncher starts apps using the same env vars as it was started with.
I'm not sure what would be the best way to fix it. Probably unset GDK_BACKEND before launching apps from Ulauncher.
Ulauncher starts apps using the same env vars as it was started with.
I suggested starting Ulauncher without GDK_BACKEND=x11, so I don't understand how that argument isn't in favor of the workaround I suggested? (which still may not work though - I haven't tried and you would know more about this).
I'm not sure what would be the best way to fix it. Probably unset GDK_BACKEND before launching apps from Ulauncher.
If you unset it, it won't revert to any user preference it may have been set to (outside of Ulauncher). For example someone might use XWayland for all their desktop apps (likely as a workaround for something else). Then it would still open a new instance of an app rather than a new window right?
I guess you could do something like this: env GDK_SHELL_BACKEND=$GDK_BACKEND GDK_BACKEND=x11, then call subprocess with env GDK_BACKEND=$GDK_SHELL_BACKEND, but it seems like stacking hacks on top of each other to negate each other's side effects imo :/
Replacing libkeybinder with a GAction would be cleaner and solve a lot of other issues, but at a cost of making it harder to use Ulauncher on DE's that doesn't support GActions.
I suggested starting Ulauncher without
GDK_BACKEND=x11, so I don't understand how that argument isn't in favor of the workaround I suggested?
Oh, I misread your suggestion initially.
Running Ulauncher without x11 backend compatibility would be ideal, indeed.
However, I have disabled that in the code because Ulauncher window was getting rendered in the top left corner of the display in Wayland. I could not figure out why. I need to take another look at that bug.
I see! Bad recommendation from me then.
Ulauncher window was getting rendered in the top left corner of the display in Wayland.
It seems to rely on X11. I wouldn't know how to do that in Wayland though. The GDK-Wayland API looks very different. Maybe you can't do it the same way because of Waylands stricter permissions, or maybe Gdk.Display could work for both.
hi @beanaroo
Could you give more examples of apps that have unexpected behavior in Wayland if Ulauncher is started with GDK_BACKEND=x11?
I am testing a fix and I see that it launches a new window Firefox even if I unset GDK_BACKEND before the lunch.
So I've tweaked the app to run on my system natively in wayland simply by deleting the code in main.py that exits if GDK_BACKEND isn't set to X11 or wayland. In Sway 1.2, ulauncher appears perfectly centered on the current active display and I can see no weird side effects. Wayland apps launch natively in wayland and X11 apps in xwayland. Only little issue is the icons appearing a little blurry on a scale 2 display as the icon size chosen is a bit on the small side.
Setting GDK_BACKEND to any value is never recommended on apps that launch other apps (not just launchers, but for instance browsers or email clients) as these will also inherit that env var and potentially break them.
Since the issues around hotkeys and positioning are gnome related, and as I suggested here https://github.com/Ulauncher/Ulauncher/issues/426 perhaps I could add another command line option to bypass that check entirely? That way is 100% opt in to people who know what they're doing.

If you can wrap a condition around that so the code for centering is still run when it should that could make a good PR. Jamedjo already posted a PR (you can find it above). I haven't looked at it, but gornostal didn't want to merge it, at least as is.
I might be wrong, but I don't believe it is possible to center a window in wayland, or rather I don't think any protocol provides with a means to request the compositor to do so and thus it's left to the compositor where to position windows as they spawn. This is one use case wlr_layer_shell does cover and has been proposed to make it to wayland proper. But for now it's not something that's available to be widely used.
Sway for instance will position any floating window like ulauncher dead on in the middle of the display as per screenshot above.
I proposed the command line argument to optionally turn off that check precisely to avoid gnome wayland users having to deal with the hotkey and window positioning issues (until such a time that a workable solution exists) while giving us sway users also a means to run ulauncher natively (as those gnome issues do not apply to us).
Sway for instance will position any floating window like ulauncher dead on in the middle of the display as per screenshot above.
gnome wayland users ... window positioning issues
gnome tweaks includes a global setting to open windows in the centre of the screen which seems to work on wayland. Between that and registering the keyboard shortcut in gnome settings, both of these issues ~are~ can be worked-around, so this feature would be useful on gnome as well.
gnome tweaks includes a global setting to open windows in the centre of the screen which seems to work on wayland.
I think that's a good workaround. Probably better than forcing users to run apps with GDK_BACKEND=x11. I'll try to implement that for the next version
@gornostal Any chance to get this fixed soon ?
I got a fix here: https://github.com/Ulauncher/Ulauncher/pull/517
@varac @luispabon should be fixed in 5.7.1. Could you verify it please?
Works for me in 5.7.1 :+1: sway 1.4 and default ubuntu 20.04 gnome wayland session.
@gornostal Thx, works for me with ul 5.7.3, ubuntu 19.10 and sway 1.4-f681d529 !
Perfect! Thanks for checking