This way we can keep the same wayland-protocols requirement, so the latest GTK3
still builds on distributions shipping older versions of wayland-protocols,
such as Debian Bullseye.
Should fix CI builds as well.
Use a separate queue to dispatch the token object exclusively, just like we
do on the GdkSurface activation paths.
Backport-of: fb68600d88d4d334f7da7d079b106a1ef14503a6
Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com>
Tools like gtk4-launch can't set surface on the activation token so
don't require it. If the compositor requires it we can't do anything
about it anyway. This avoids a critical:
(gtk4-launch:23497): Gdk-CRITICAL **: 17:07:24.704: gdk_wayland_surface_get_wl_surface: assertion 'GDK_IS_WAYLAND_SURFACE (surface)' failed
Fixes: be4216e051 ("gdk/wayland: Support the xdg-activation wayland protocol")
Signed-off-by: Guido Günther <agx@sigxcpu.org>
Backport-of: 4d741bac98f906796d61eebfb4f74f5b1cecb2b6
Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com>
And notify the shell about it. This is done through the
gtk_shell1.notify_launch request added in gtk-shell v3. All the plumbing
on the way to the activated application is already in place to transfer
the startup ID, so the other side just has to reply with
gtk_surface1.request_focus.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/624
