We want to claim the event sequence in the click gesture when appropriate,
such as activating a row or clicking an editable cell, but this is currently
done too early, preventing other gestures for drag-and-drop and rubberband
selection entirely.
Fixes#3649Fixes#3985Fixes#4669
gtk_tree_view_top_row_to_dy, which is called from GtkTreeView's
size_allocate function, changes the adjustment value. Since this
conflicts with the animation when changing the active row, bail
out until the animation is finished.
Fixes#4550
When a GtkTreeView scrolled horizontally, it was not possible to
select rows outside the initial area due to an erroneous comparison
between widget and bin window coordinates.
Original change to widget coordinates occurred in commit
a0de570e47
Functions already exist for providing a unique drag action for gdk_drop_finish().
Reuse these functions in the drag_enter/motion callbacks, since they require
a unique action as the return value.
Fixes#3187
Those property features don't seem to be in use anywhere.
They are redundant since the docs cover the same information
and more. They also created unnecessary translation work.
Closes#4904
gtk_tree_view_row_activated and the ::row-activated signal
can (and do) receive NULL for the column occasionally.
This is an introspection api change.
Fixes: #3828
We already skip them on the edited cell widget, but it's also a problem for
header buttons. Overall, there's no real reason to let it propagate here.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3996
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.
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.
Instead of hardcoding icon names in the widget, use
sort-indicator.ascending and sort-indicator.descending styles
and set the icon to use with -gtk-icon-source. This lets themes
change the icon that is used here, without forcing all uses of
pan-up/down-symbolic to be treated the same.
Document this in the treeview CSS docs.
Fixes: #3577
The coordinates are already widget-local here, not transformed by the
adjustment positions. Using the adjustment value here ends up pushing
the entry far from the left border.
The correct minimum value here is 0, which matches the treeview left
border.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3009
GtkTreeView.get_tooltip_context() takes an inout X and Y coordinates,
but the "out" side is a side effect: the conversion from widget-relative
to bin window-relative coordinates is not documented, and can be done
using public API, if needed.
GtkIconView.get_tooltip_context() follows the same pattern, and takes
two inout arguments for the coordinates, but it does not change them any
more, after GtkIconView's bin window was dropped in commit 8dc5e13e.
There's really no point in having these `inout` arguments, and while
GtkTreeView and GtkIconView are certainly de-emphasised in GTK4, and we
nudge developers to move to the new list views, we should take advantage
of the API break to remove warts.
Anybody who keeps their own CSS nodes around or wants to order CSS nodes
different from widgets will from now on have to do it manually all the
time.
This is outdated behavior, nobody should be doing either of those two
things.
Also, the correct case is much more common, and not doing it
automatically was causing bugs.
Fixes#3280
In gtk_tree_view_build_tree with recurse=TRUE, the TEST_EXPAND_ROW
signal might invalidate the child iterator. Getting the iterator after
the signal (instead of before) fixes the issue.
Fixes https://gitlab.com/inkscape/inkscape/-/issues/1879
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
Porting code from GTK 3 without the ability to subclass GtkTreeView
directly can cause an extreme amount of pain on application developers.
It can also complicate performance when it comes to dealing with
encapsulation as the outer widget would also encapsulate the GtkScrollable
implementation from GtkTreeView, typically through GtkViewport.
Fixes#2936
