WayfireWM
panel/menu: launch apps with a valid xdg-activation token
Creating a Gdk::AppLaunchContext from the current display and providing it to Gio::AppInfo::launch() takes care of this.
This can be useful if a compositor is set not to focus newly created toplevels without a valid xdg-activation token (see https://github.com/WayfireWM/wayfire/pull/2627)
I've tested this and it works as expected, The same can be said for equivalent changes to the gtk4 branch I have, so I'm going to apply this there too.
Shouldn't similar changes also be applied for
panel/launchers?
Actually yes :)
I've added an implementation, but it is not working. My hunch is that since the panel does not get keyboard focus, generating a token runs into some problem. Running with WAYLAND_DEBUG, it seems to me that the issue is on the GTK side:
[4077976.332] {Default Queue} wl_pointer#18.button(79, 44445793, 272, 1)
[4077976.367] {Default Queue} wl_pointer#18.frame()
...
[4078003.170] {Default Queue} -> xdg_activation_v1#20.get_activation_token(new id xdg_activation_token_v1#48)
[4078003.186] -> xdg_activation_token_v1#48.set_serial(79, wl_seat#21)
[4078003.198] -> xdg_activation_token_v1#48.commit()
[4078003.446] xdg_activation_token_v1#48.done("4e637e06f95345fa497278d8f4fe51f0")
[4078003.474] -> xdg_activation_token_v1#48.destroy()
For some reason, the panel's surface is not set -- compare this to the case of using the menu:
[4202341.600] {Default Queue} wl_pointer#18.button(140, 44570159, 272, 1)
[4202341.686] {Default Queue} wl_pointer#18.frame()
...
[4202404.193] {Default Queue} -> xdg_activation_v1#20.get_activation_token(new id xdg_activation_token_v1#51)
[4202404.206] -> xdg_activation_token_v1#51.set_serial(140, wl_seat#21)
[4202404.215] -> xdg_activation_token_v1#51.set_surface(wl_surface#38)
[4202404.220] -> xdg_activation_token_v1#51.commit()
[4202404.349] xdg_activation_token_v1#51.done("67014538372d68f7958e1a7d441c6d58")
[4202404.370] -> xdg_activation_token_v1#51.destroy()
which works well.
(note: this is with setting the check_surface = true option from https://github.com/WayfireWM/wayfire/pull/2527)
On assessing again, we didn't include keyfile.set_string("Desktop Entry", "StartupNotify", "true"); in launchers.
I see @dkondor helpfully referenced sources, but it's lost on me as to what they mean in context. Hold off closing until this discrepancy is addressed.
@dkondor Does this change not work without startup notify?
Unfortunately, the links I added became outdated. It should be the following: https://gitlab.gnome.org/GNOME/glib/-/blob/0f95b18a7ba0f0ed6182917459cf8f9233862003/gio/gdesktopappinfo.c#L1970 https://gitlab.gnome.org/GNOME/glib/-/blob/0f95b18a7ba0f0ed6182917459cf8f9233862003/gio/gdesktopappinfo.c#L2957
The same logic in the latest master: https://gitlab.gnome.org/GNOME/glib/-/blob/618d45cc830359109caa99767fb179caedb04657/gio/gdesktopappinfo.c#L2022 https://gitlab.gnome.org/GNOME/glib/-/blob/618d45cc830359109caa99767fb179caedb04657/gio/gdesktopappinfo.c#L3036 https://gitlab.gnome.org/GNOME/glib/-/blob/618d45cc830359109caa99767fb179caedb04657/gio/gdesktopappinfo.c#L3217
Basically, if this key is not set, then the startup_notify member will be false, and then the relevant environment variables will not be passed to the child process (or not sent via DBus).
However, as I wrote above, I could not get this case to work properly. I believe the reason is that GTK will not generate a valid xdg-activation token if it does not think we have the keyboard focus. This might be different in GTK4 though (also given the architectural change of gtk-layer-shell-4), but I haven't had the time to test though. Note that on Wayfire, this is not very apparent, since new windows always get focused (I have the linked PRs to change this, but will have to revisit them as they don't work properly in all cases with layer-shell surfaces).
I haven't looked at the gtk4 version yet, but will try to test if it works with it