G_ENABLE_DEBUG is tied to the meson builttype property, so building with "plain"
results in G_ENABLE_DEBUG not being defined and the GTK_DEBUG env var just gets ignored
for that build.
Since it can be confusing that GTK_DEBUG has no effect print a warning message instead.
Fixes#2020
In PyGObject gdk_init() is called before gtk_init() and thus there is
already a default display open when gtk_init() is called.
The code assigning the display to the debug_flags struct gets only
called when the default display changes, which never happens
when there already is one. As a result GTK_DEBUG=interactive
doesn't do anyting with Python apps.
This makes it call the change callback in case a display is already
there.
See https://gitlab.gnome.org/GNOME/pygobject/issues/166
This fixes a fallout from 8a7d0ab481 where the error wasn't being
set when a display couldn't be opened right after parsing the
commandline.
It also fixes an older bug where the error would be left unset if the
commandline had already been parsed before (ie. when gtk_initialized
is TRUE).
https://bugzilla.gnome.org/show_bug.cgi?id=771959
The existing documentation seems to suggest that gtk_init_check will
ignore any failure to parse the commandline arguments, and that its
return value only depends on its ability to initialize the windowing
system. That's not true.
Be more explicit to avoid misunderstandings.
https://bugzilla.gnome.org/show_bug.cgi?id=771959
_gtk_accessibility_init() only gets called if the default
display changes, but in case gdk_init() is called before gtk_init()
the default display is already set and no property notification occurs.
This can happen quite easily in pygobject where
"from gi.repository import Gdk, Gtk"
will call gdk_init() followed by gtk_init() in the Python overrides.
This fixes it by checking for a default display in all cases.
Defer a11y initialization until we have a display. A11y initialization
causes widget classes to be initalized, which in turn needs some
backend-specific information about modifier masks that can't be
obtained before we have a display.
https://bugzilla.gnome.org/show_bug.cgi?id=736125
This is implicitly done for us in the case of grabs on windows from other
groups, but we must perform this check explicitly for grabs with
owner_events=True on windows from the same group, in that case the window
would handle the events as if there was no grab.
https://bugzilla.gnome.org/show_bug.cgi?id=752327
Popovers may be spawn when there's GTK+ grabs somewhere else (eg.
text selection popover/handles in an entry in a modal popover). When
this happens, events go to the grab widget (in this case the modal
popover) and are effectively ignored by the event widget, even though
it's can be conceptually a child of the grab widget.
To get away with this, tweak a bit gtk_main_do_event(), so events going
to popovers that are related to grab_widget or a child of it are received,
as it would happen with regular children of grab_widget.
https://bugzilla.gnome.org/show_bug.cgi?id=750993
The changes in commit 13e22e2030 made
_gtk_window_check_handle_wm_event() indirectly depend on
gtk_get_current_event_time() which relies on the current event being
available on the current_events stack.
Since the current event is only pushed on the stack afterwards we get
an invalid timestamp which breaks ewmh window moving.
This fixes the issue by pushing the current event before we start
relying on it being there in gtk_main_do_event() and, as a byproduct,
also fixes a potential memory leak when we have a rewritten event and
return early due to _gtk_window_check_handle_wm_event() being TRUE.
https://bugzilla.gnome.org/show_bug.cgi?id=750384
The gesture is hooked to the capture phase, so it works for buttons in
header bars and whatnot. In order to be friendly to the widget it is
capturing events from, an ugly hack is in place to avoid capturing
events when the target widget has a gesture that would consume motion
events.
The current way of exposing GDK API that should be considered internal
to GTK+ is to append a 'libgtk_only' suffix to the function name; this
is not really safe.
GLib has been using a slightly different approach: a private table of
function pointers, and a macro that allows accessing the desired symbol
inside that vtable.
We can copy the approach, and deprecate the 'libgtk_only' symbols in
lieu of outright removal.
https://bugzilla.gnome.org/show_bug.cgi?id=739781
Introduce a new debug category "actions" and write some messages from
GtkActionHelper about if we can find the actions or not.
We will probably soon want to add some similar messages to
GtkMenuTrackerItem.
https://bugzilla.gnome.org/show_bug.cgi?id=733965
Prevent a segfault in unknown circumstances, and break the ignore
deprecations wrapper out from the if statement so that we don't
cover too much ground by accident.
This reverts commit b875572f2a.
Apps like Abiword, gnumeric and gnome-chess, and toolkits like
ClutterGTK were all using this for various purposes, and this made them
break. Bring back this feature for now.
It still won't work under Wayland.
gtk_widget_set_double_buffered is now deprecated, and we don't support
non-double-buffered widgets. This means that under normal circumstances,
paints are never outside of a begin_paint / end_paint sequence, which
natively-double-buffered backends like Wayland can't possibly support.
