This allows developers to modify the pango context that is used when
rendering text within the text view.
Such access can be useful to alter how rounding occurs with API such as
pango_context_set_round_glyph_positions() and is needed by GtkSourceView
for proper placement of glyphs within the overview map.
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.
Stash away the device timestamp when obscuring
the pointer, and compare it when we decice whether
to unobscure it. This fixes a problem where synthetic
motion events would make the cursor reappear
prematurely.
Fixes: #3792
If multiple nested widgets have drag sources on them, both using bubble
phase, we need to reliably pick the inner one. Both of them will try to
start dragging, and we need to make sure there are no situations where the
outer widget starts drag earlier and cancels the inner one.
Currently, this can easily happen via integer rounding: start and current
coordinates passed into gtk_drag_check_threshold() are initially doubles
(other than in GtkNotebook and GtkIconView), and are casted to ints. Then
those rounded values are used to calculate deltas to compare to the drag
threshold, losing quite a lot of precision along the way, and often
resulting in the outer widget getting larger deltas.
To avoid it, just don't round it. Introduce a variant of the function that
operates on doubles: gtk_drag_check_threshold_double() and use it instead
of the original everywhere.
Check the text handle role, instead of looking for the other handle
visibility. The other handle may be invisible during selection mode
(e.g. pointing to offscreen contents). This fixes both this code
switching to cursor mode out of the blue, and possible crashes later
on as this handle might be hidden in the process, while its own event
controller is handling events on the parent surface.
The gtk_text_view_set_handle_position() function called some lines above
takes care of handle visibility already, also accounting for other
conditions (e.g. whether the handle points to contents onscreen).
Forcibly showing handles here misbehaves if the handle should stay hidden,
and somewhat expensively as it involves creating and throwing a native
surface every time.
With the scrolledwindow drag gesture not claiming the sequence immediately,
we end up placing the cursor (and undoing the previous selection) each time
we scroll.
There is already handling too short drags in ::drag-end, so let this code
handle touchscreens as well.
If the gesture becomes captured (e.g. from a parent scrolledwindow), we
leave some things in the air. Clean these up properly. This is recurrent
with touch scroll.
When we start a dnd of the selection in the drag-update handler,
set the gesture state to denied. Otherwise, we get more drag-update
signals, and things get really confused, leading to no dnd and
sadness.
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
