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
Add a pango call to create the fontmap already in gtk_init.
This will let us hide the cost of FcInit() (which on font-heavy
systems can be ~100ms) in a thread, on the pango side.
Make GdkEvents hold a single GdkDevice. This device is closer to
the logical device conceptually, although it must be sufficient for
device checks (i.e. GdkInputSource), which makes it similar to the
physical devices.
Make the logical devices have a more accurate GdkInputSource where
needed, and conflate the event devices altogether.
To build a better world sometimes means having to tear the old one down.
-- Alexander Pierce, "Captain America: The Winter Soldier"
ATK served us well for nearly 20 years, but the world has changed, and
GTK has changed with it. Now ATK is mostly a hindrance towards improving
the accessibility stack:
- it maps to a very specific implementation, AT-SPI, which is Linux and
Unix specific
- it requires implementing the same functionality in three different
layers of the stack: AT-SPI, ATK, and GTK
- only GTK uses it; every other Linux and Unix toolkit and application
talks to AT-SPI directly, including assistive technologies
Sadly, we cannot incrementally port GTK to a new accessibility stack;
since ATK insulates us entirely from the underlying implementation, we
cannot replace it piecemeal. Instead, we're going to remove everything
and then incrementally build on a clean slate:
- add an "accessible" interface, implemented by GTK objects directly,
which describe the accessible role and state changes for every UI
element
- add an "assistive technology context" to proxy a native accessibility
API, and assign it to every widget
- implement the AT context depending on the platform
For more information, see: https://gitlab.gnome.org/GNOME/gtk/-/issues/2833
