Claiming early makes the contents unable to react to the touch press
event. Do this on GtkGestureDrag::update past a threshold, so the
child widget(s) can claim before the scrolledwindow does.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3125
This API is kinda stuck in the GdkEvent days, we now negotiate ownership
of the input sequence via GtkGestures. Remove it as it reflects a way to
work that was not exactly accurate and it will turn plainly wrong soon.
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
Check correctly that the captured motion events are emitted towards the
content or one of the scrollbars, in order to have it set the expected
"over" state depending on whether the drag begins from the scrolledwindow
content or one of the scrollbars.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2879
In 99.9% of all cases, these are just NULL, NULL.
So just do away with these arguments, people can
use the setters for the rare cases where they want
the scrolled window to use a different adjustment.
This was not working in the case that the existing child
is not a scrollable. It showed up as crashes of the
scrolling benchmark in gtk4-demo when switching examples.
Add back a property that determines whether an individual
widget will accept focus or not. :can-focus prevents the
focus from ever entering the entire widget hierarchy
below a widget, and :focusable just determines if grabbing
the focus to the widget itself will succeed.
See #2686
We want to remove GtkBin and GtkContainer as they don't
provide much useful functionality anymore. This requires
us to move get_request_mode and compute_expand down.
We have to implement GtkBuildable, in order to keep
the <child> element in ui files working for aspect
frames.
See #2681
After the :can-focus change in the previous commit, widgets
need to set suitable focus and grab_focus implementations
to implement the desired focus behavior.
This commit does that for all widgets.
Restructure the getters for event fields to
be more targeted at particular event types.
Update all callers, and replace all direct
event struct access with getters.
As a side-effect, this drops some unused getters.
