Tracking it through the GtkGestureClick becomes a bit cumbersome for
handling of simultaneously pressed buttons. We can track ::stopped,
but that also emits for a number of situations where we want drag to
continue.
However, the GtkGestureDrag is grouped with the click gesture, and
knows better when to finish the drag gesture (not just because of a
button release), so hook drag and zoom mode finalization there.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3426
The nameless, faceless gizmos inside a range do not
contribute to the accessible experience at all, lets
not add them to the tree. All the accessible functionality
is on the main widget (either a scale or a scrollbar).
For the various uses of GDK_WINDOWING_QUARTZ, we need to use
alternatives from GDK_WINDOWING_MACOS.
Some minor loss of functionality is here, such as icons sent with
application menus. That can certainly be added back at a future
point.
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
The gtk_gesture_group() call is not a commutative operation, it
takes two gestures, maybe detaches the first one from its current
group, and adds it to the same group than the second gesture.
With the flipped argument order here, GtkRange was actually detaching
the same gesture in order to group it with a second one two times, so
the desired effect to group all 3 gestures was not achieved.
Fixes autoscroll as the drag gesture is now actually grouped with the
click one, so drag offsets can be accessed from the autoscroll
timeout.
Always keep the order:
- [value]
- [marks.top]
- [marks.bottom]
- trough
Which makes sense given the rendering order. Slider should be drawn
after the marks.
Makes it possible to simply remove the custom snapshot implementations
in scale and range. And Adwaita does not depend on the node order
anyway.
It feels slightly wrong to have GtkOrientable operate on widgets, but at
least what happens when an orientable widget changes orientation should
be part of GtkWidget.
This will allow to add more state changes without accessing widget state
from the outside of gtkwidget.c.
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.
Just queue_resize()ing the range itself doesn't work as it will just
re-allocate all the child widgets (i.e. just the trough) to its old
position and size.
This will be used to let the inspector and other users
pick insensitive widgets again. For now, update all
callers to pass no flags, preserving the current
behavior.
The entire color scale hack is still done in GtkRange, which draws the
color scale in the range gizmo. So, to correctly redraw the color scale
when setting a new color, we need to redraw the proper widget and that's
the trough widget.
Fixes#1453
