GNOME Bugzilla – Bug 735531
Make tooltips use subsurfaces on wayland
Last modified: 2014-08-28 14:43:00 UTC
On wayland, tooltips windows currently get shown as a xdg_popup, which is not designed for tooltips, as it involves compositor grabs, and actually takes the focus away of the window being tipped about. I'm attaching a small patch that uses the same trick on popovers than on entry completion windows, so tooltips are rendered on a subsurface, and act on wayland as you'd expect.
Created attachment 284618 [details] [review] tooltip: Use subsurfaces on wayland This places tooltips in the right place, and avoids having those attempt to steal the focus.
Review of attachment 284618 [details] [review]: ::: gtk/gtktooltip.c @@ +910,3 @@ + GTK_WINDOW (window_widget)); + else + gtk_window_set_transient_for (GTK_WINDOW (tooltip->window), NULL); If we ever hit the 'no transient parent' case, will that break with subsurfaces ? What do we do in that case under Wayland ?
(In reply to comment #2) > Review of attachment 284618 [details] [review]: > > ::: gtk/gtktooltip.c > @@ +910,3 @@ > + GTK_WINDOW (window_widget)); > + else > + gtk_window_set_transient_for (GTK_WINDOW (tooltip->window), NULL); > > If we ever hit the 'no transient parent' case, will that break with subsurfaces > ? What do we do in that case under Wayland ? In that case the wl_subsurface is internally lost, but the wl_surface may remain to create a new wl_subsurface interface for it, the surface is no wl_shell_surface nor xdg_surface either, so is nothing the compositor would show. In the specific case of tooltips, the tooltip window is also on its way to being hidden, which would mean the wl_surface is gone too, until both resources are created when the tooltip is needed again (and set_window()/show() happens again on it)
Review of attachment 284618 [details] [review]: ok then
Attachment 284618 [details] pushed as 3df8b95 - tooltip: Use subsurfaces on wayland