Commit adba0b97 fixed missed pointer crossings by using a helper function that
was already present and looked like did everything that was needed. However
this function was oriented to keyboard focus and it also did update the related
widget state. Doing these changes on pointer-based crossing was misuse, and
could cause weird interactions with keyboard focus management.
Fix this by using gtkmain.c gtk_synthesize_crossing_event() that is in fact
oriented to pointers.
Fixes: adba0b97 (gtkwindow: Synthesize pointer crossing events on state changes)
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5094
Instead of passing an event and figuring out coordinates from it, pass
directly the toplevel coordinates so that we can use this outside event
handling.
All callers have been updated to pass the coordinates, in practical effects
they were already based on the GtkNative.
Following what was done for pinch/swipe events, give hold gestures their
own distinct sequence as well. Without this it was NULL, which was already
distinct to other touchpad gestures.
This allows inverting the default text-direction in an application for
debugging, testing, and QA purposes. IDEs such as Builder may automate this
to encourage more application developers to test with a text-direction
different than their own.
These are meant to always redirect events to the grabbing surface,
even for other surfaces of the same client. We weren't doing that
(instead letting the event go through unmodified), fix this handling
so GTK sees the events consistenty.
If a grab is held on a toplevel surface tree, and events happen on a
different surface tree from another toplevel/window group, we rewrite
these events so they look like generated on the window group that
holds the grab, but it missed that coordinates would fail to be
translated, so these would stay unchanged and "pointing" to random
parts of the toplevel that is holding the grab and handling the events.
Since off-surface coordinates are not specially meaningful, and in
fact impossible to obtain in some backends, just fake the coordinates
making it sure that all rewritten events point outside the surface.
The grabbing window will still handle the events, but the coordinates
in these will be harmlessly moot.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4760
Despite touchpad gestures having a sequence, these must use the logical
pointer focus. Avoid using the sequence for GtkPointerFocus lookups with
those events, in order to ensure those events make it all the way to the
intended target.
This is fallout from adding GdkEventSequence information to touchpad
gestures.
It makes sense to connect the begin/update/end events
for touchpad swipes and pinches in a sequence. This
commit adds the plumbing for it, but not backends
are setting sequences yet.
This grab-induced crossing event may come from outer means while there are
buttons pressed (e.g. WM window drags/resizes in X11), the implicit active
state should be undone in that situation.
Also, separate the handling of GDK_LEAVE_NOTIFY, as it's fundamentally
different from GDK_TOUCH_END/CANCEL handling.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4416
Remove a boatload of "or %NULL" from nullable parameters
and return values. gi-docgen generates suitable text from
the annotation that we don't need to duplicate.
This adds a few missing nullable annotations too.
Currently, the implicit grab is broken on the first button release,
in the case of pressing multiple buttons simultaneously. This means
that we emit crossing events early, and the next button releases
are sent to the pointer focus widget instead.
Consider the implicit grab effective until all buttons are released,
and only unset the pointer implicit grab (and emit crossing events)
after there are no further buttons pressed. We do this by checking
event modifiers, given button release events do contain the modifiers
in effect at the time the event was generated, we have to look for
exactly one active button modifier.
Fixes weird pointer states after pressing multiple buttons on a
widget.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3426
If an active grab gets undone on button press (e.g. closing a menu), we
will receive a button release on the new target even though it didn't handle
the button press, and disable ::active state.
This causes warnings when handling the button release, as it tries to undo
::active state that is not really there.
In order to fix this, check that the pointer focus actually had an implicit
grab at the time of receiving the button release, before trying to unset
the ::active state.
Currently GTK can be built with G_ENABLE_DEBUG which enables various debug code and parsing
of those env vars, or without, which instead of parsing them prints a warning if they are set.
While building with G_ENABLE_DEBUG isn't strictly needed it's the only way to make GTK_DEBUG=interactive work,
which is a nice thing to have always.
This enables parsing of those env vars in any case and allows specific values being marked as also
available when not built with G_ENABLE_DEBUG (interactive for example). If not built with G_ENABLE_DEBUG
then all unavailable values will be marked as such in the help output and a note is added that
GTK needs to be built with G_ENABLE_DEBUG to use them, which should help discoverability.
An implicit grab means some button is down, reset the active state
only in that case when we get a grab broken event.
Avoids active state accounting warnings when we do get active grabs
broken (e.g. after selecting a menu option).
We may have the situation of multiple touchpoints in the same
widget, or combinations with other devices. Stack those ::active
states are preserved on widgets on all but the last pointer/touch
going away.
We are not propagating focus change events, and that is the only
place where we are listening for focus change events. If GtkWindow
does not see focus-in events for its popovers, we end up with
inadvertendly inactive windows.
Fixes: #3240
Failure to do so makes the old pointer focus target
'sticky', because we end up ignoring the result of
picking the pointer focus until a motion event comes
in.
Fixes: #3172
We are reusing the GtkCrossingData struct for multiple
calls here, so we need to make sure that the targets
stay alive from beginning to end.
Fixes: #3090
