It won't stand true anymore that the GdkEventType argument is the
first field of the GdkEvent* structs. All callers have been updated
to use event->any.type instead.
For a start, this makes gtk_main() work different from g_main_loop_run()
calls.
But most importantly, modern GDK does proper syncing itself and doesn't
need to rely on a catch-all to get it right.
This patch makes that work using 1 of 2 options:
1. Add all missing enums to the switch statement
or
2. Cast the switch argument to a uint to avoid having to do that (mostly
for GdkEventType).
I even found a bug while doing that: clearing a GtkImage with a surface
did not notify thae surface property.
The reason for enabling this flag even though it is tedious at times is
that it is very useful when adding values to an enum, because it makes
GTK immediately warn about all the switch statements where this enum is
relevant.
And I expect changes to enums to be frequent during the GTK4 development
cycle.
Those should be interpreted by widget-local gestures, not guessed at a
high level with no notions of the specific context. Users will want
GtkGestureMultiPress to replace these events.
This change is made for consistency, it doesn't make sense to expose
one-way propagation, as it can only break expectations from GTK+. This
function might be made entirely private in the future, but it still
makes sense to do this in one go for our internal usecases.
As we now refrain from sending the crossing events if there's an
implicit grab, those events must be sent on button release when
the implicit grab is broken.
Check the grab widget (both explicit and implicit) and check for a cursor
from the target widget up to this grab widget. If the target widget is
outside the grab widget, only the grab wigdet's cursor will be checked.
This also means that we have to ensure the cursor is updated on button
releases, as an implicit grab being deactivated must trigger a cursor
lookup from the target widget.
Unlike GTK+ grabs which are global to all/one device, the implicit grab
is per focus, which means each may have implicit grabs on different or
the same widget.
Implement target finding per-pointer/touchpoint through GtkPointerFocus and
_gtk_toplevel_pick(). Focus changes are handled through the emission of
crossing events between the old target and the new one.
gtk_init() removed its support for supporting arguments, so we ought to do
likewise for Windows, which actually defines items that call gtk_init()
the old way (and also get rid of argument support in those functions,
since the direction is to not support them).
https://bugzilla.gnome.org/show_bug.cgi?id=773299
We want to simplify our initialization code and remove all commandline
argument handling from it. The first stop for this is to reduce the
number of gtk_init variants we have.
This causes the snapshotting algorithm to dump all widget nodes into
their own container node. We then name that group accordingly (ie
"GtkSwitch<0xdeadbeef>") so you can easily see which node belongs where.
The feature is toggleable in the inspector's visual tab.
There's a few problems with it, becuse GtkSnapshot optimized container
nodes away if they are not needed, so we are losing some widgets...
Includes the ability to turn on updates in the inspector. Animations are
now run via a tick function which allows us to neatly overlay a
semi-transparent red rectangle and fade it out over time.
It also probably enables way more, but somebody with more UI neatness
than me needs to figure out what it eanbles first...
The update tracking code was ugly and using deprecated drawing APIs. It
was also in the wrong place.
So instead of trying to keep it working, I'll remove it. We need to find
a better way to put it and make it work there.
_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
