GtkListBox is not a windowed widget anymore so we can't use
gtk_widget_get_window. Just directly access priv->view_window instead to
get the right window.
For a menu mode CB with wrap_width == 0 and an active item, that item is
selected in gtk_combo_box_menu_popup. Selection causes the MenuShell to
activate and hence take a grab. This was done before the menu was popped
up. A patch distributed in Debian sid - after being proposed on our BZ -
revealed that on the 1st popup of any such ComboBox, within grab_add,
the MenuShell's toplevel's GdkWindow is NULL. This causes a Gdk-CRITICAL
assertion fail on the 1st time opening any such CB, on Debian and if
that patch were merged to GTK+. By selecting after popup, we ensure the
MenuShell is realised before its grab_add and so avoid the critical.
https://bugzilla.gnome.org/show_bug.cgi?id=771242
This way, we don't spam criticals when GL is not available. Instead, we
print a useful debug message to stderr and continue with the Cairo renderer.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
and remove gsk_renderer_get_for_display().
This new function returns a realized renderer. Because of that, GSK can
catch failures to realize, destroy the renderer and try another one.
Or in short: I can finally use GTK on Weston with the nvidia binary
drivers again.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Instead of having a gsk_renderer_set_window() call, pass the window to
realize(). This way, the realization can fail with the wrong window.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
gdk_window_get_toplevel() walks up the windows tree looking for the
corresponding toplevel window, but needs to account for subsurfaces as
well on Wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=775319
We were producing org.symbolic.png from org.gnome.Recipes-symbolic.svg,
which is not useful. Look for the last dot in the original name, to
produce the expected org.gnome.Recipes-symbolic.symbolic.png instead.
gskrenderer.c includes gdk/wayland/gdkwayland.h and as a consequence
we need to be able to locate wayland's headers in case they are not
in standard location.
https://bugzilla.gnome.org/show_bug.cgi?id=775038
Now that subsurfaces can be created as child of another GdkWindow (and
not just the root window), they must be placed according to the location
of their parent, i.e. the abs_x/abs_y must be updated and taken int
account when placing and moving subsurfaces under Wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=774917
