This isn't really useful, as it totally changes the API. But it serves as a
base to play around with scrolling using partial pixels for smoother
deceleration.
GtkAdjustment have values that are often tied to the "virtual" allocation
size of a widget, such as a GtkScrollable. Thusly, when size_allocate() is
called on GtkScrollable, the adjustment will emit ::changed. But a
size_allocate() indicates we're in the GDK_FRAME_CLOCK_PHASE_LAYOUT and
that is too late to perform changes that will affect allocation.
Therefore, this defers handling of the changed signal to the next frame so
that we do not perform operations that can cause widgets within the
hierarchy to loose their allocation.
This fixes a very common issue, where we see something like:
Trying to snapshot GtkGizmo 0x... without a current allocation
which was caused by GtkViewport changing it's adjustment in size_allocate()
and cascading to a GtkScrolledWindow->GtkScrollbar->GtkRange->GtkGizmo.
# Conflicts:
# gtk/gtkrange.c
This commit implements the idea brought up in #5032, and provides a
simple function for GtkEditable implementations using a delegate object.
The accessible state is proxied from the outher GtkEditable to the
delegate.
The `get_child_at_index()` API model comes from AT-SPI, and it's not an
efficient design, especially when coupled with large widgets.
Replace `get_child_at_index()` with `get_first_accessible_child()` and
`get_next_accessible_sibling()`.
That allows efficiently retrieving all the children, simplifies the
implementation of GtkAccessible in GtkWidget and closely resembeles the
GtkWidget API.
Getting the last child and previous sibling for iterating backwards is
not a part of the interface at the moment, but they can be added at a
later date.
Note that this change required tracking the next stack page in
GtkStackPage.
Reduce our dependency on linked lists; pointer arrays are better at
cache locality.
Additionally, we can avoid quadratic behaviors when finding a child at a
given index.
Otherwise, we end up with a single long row
pushing the content of all the other rows
off to the left, which is much worse than
ellipsizing.
Fixes: #4710
This is currently just used as a convenience storage of the startup ID
between the GtkApplication and the GtkWindow (after it's ready to notify
on it).
This could be untangled in the GTK layers so there is no involvement
from GDK in keeping the startup ID around, in the mean time just deprecate
these gdk_wayland* API calls.
These pieces were added in commit 8d2f81cca4, but are no longer
necessary since there's no capture_button_press special behavior
toggle.
This can be simplified again.
Do not get a GdkEvent first and foremost, and only do that in the
parts where the GdkEvent is absolutely necessary (i.e. popping up
the WM menu for the window).
We can abstract widgets about the specific ongoing sequences that
are triggering a GtkGesture. This used to be more necessary in
GTK3 world where complex widgets might have required handling
different events in different areas, but in GTK4 world that would
be done with multiple widgets.
This is no longer necessary to carry forward.
It does not require special knowledge about the ongoing event
sequences, and it can instead trust the event controller. Make
it use gtk_gesture_set_state() generically.
