If GtkExpander:sensitive was FALSE, the arrow still got the normal fg
colour, which made it look clickable, in contrast to the adjacent label.
Fix this by adding selectors to catch the applicable :disabled states.
Note: Needing these may indicate an oops in generic styles elsewhere,
but I couldn’t see any, so let’s just get it looking right for now.
https://gitlab.gnome.org/GNOME/gtk/issues/146
AM_PATH_GTK_3_0 uses AC_PATH_PROG for finding pkg-config. Unfortunately,
that will find the build architecture pkg-config which in turn will miss
the host architecture gtk+3.0. What must be used here is the host
architecture pkg-config and that is found with AC_PATH_TOOL.
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894069
Reviewed-by: Simon McVittie <smcv@debian.org>
Fixes: #133
Fixes two things: 1) As GTK+ can be coerced into using the wayland IM
module despite the compositor not implementing the interface, all paths
not checking for global state before sending requests are prone to
crashes, this one fell hit this pitfall.
And 2) ensures the tap gesture only triggers TOGGLE_INPUT_PANEL if the
widget IM is focused. This is a possibility on eg. WebKit pages, where
its IM is only focused as long as a form element in the page is focused.
Tapping elsewhere shouldn't toggle the OSK.
https://gitlab.gnome.org/GNOME/gtk/issues/114Closes: #114
…the wayland registry.
Wnen _gtk_im_module_get_default_context_id calls
match_backend (context_id) and the default GdkDisplay
is wayland, match_backend() should return TRUE only if
gdk_wayland_display_query_registry (display, "gtk_text_input_manager")
returns TRUE.
When the widget gets finalized it clears the widgetnode and gtk_css_widget_node_get_widget
returns NULL. Guard against gtk_css_widget_node_get_widget() returning NULL like in other
places.
See https://gitlab.gnome.org/GNOME/pygobject/issues/28#note_82862
Since the Cairo build files for Visual Studio does not really generate
the pkg-config files for us, and we stopped making makeshift ones in
gobject-introspection, stop making the .pc files we generate here refer
to the Cairo .pc's, and instead make them link directly to
cairo-gobject.lib and cairo.lib.
If @menu_label == NULL, we create a default page->menu_label. This took
@tab_label.get_label() and passed that to page->menu_label.set_text().
This is wrong because we set the plain text of the menu_label from the
rich text of @tab_label. So, if @tab_label used mnemonics or markup, our
menu_label got the raw underline or markup tags shown in it as raw text.
As we call set_text() on the menu Label, the fix is to be symmetric: use
@tab_label’s get_text() as source, as that strips underlines and markup.
It’s not worth making the default Label ‘inherit’ :use-underline/markup;
that’s a slippery slope, and users wanting such things can just create a
fully fledged GtkLabel to pass as @menu_label to suppress the default.
https://bugzilla.gnome.org/show_bug.cgi?id=705509
If a window is unmapped by the client while gdk is processing updates,
(for example Firefox un-mapping its window on Expose events), the
windowing backend resources might be lost (for example with Wayland)
which can cause a crash in end_paint().
Make sure we drop the cairo surfaces as well when hiding the surface,
that will avoid the crash in gdk_window_impl_wayland_end_paint() when
trying to attach the staging cairo surface to a released wl_surface,
these will be recreated when needed when the surface becomes visible
again and there is no need to keep such buffers around for a surface
which is not visible anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=793062
This commit adds support the stable version of the xdg-shell protocol.
Support for the last version of the unstable series is left intact, but
will not receive new features.
The stable version is prioritized above the older version.
https://bugzilla.gnome.org/show_bug.cgi?id=791939
Otherwise, the + or - button might change sensitivity based on whether
it can be used to wrap, but without ensuring we update its state, the
ability to :wrap isn't reflected until something else triggers a draw.
https://gitlab.gnome.org/GNOME/gtk/issues/88
