When GTK_EVENT_CONTROLLER_SCROLL_DISCRETE is set, accumulate deltas also
for mouse scroll so a high-resolution mouse wheel click behaves in the
in the same manner as a low-resolution mouse wheel click.
Instead of calculating the discrete scroll deltas in
GtkEventControllerScroll, move that code to the event constructor and
access the precalculated values using gdk_scroll_event_get_deltas.
Refactor, no functional changes.
Commit adba0b97 fixed missed pointer crossings by using a helper function that
was already present and looked like did everything that was needed. However
this function was oriented to keyboard focus and it also did update the related
widget state. Doing these changes on pointer-based crossing was misuse, and
could cause weird interactions with keyboard focus management.
Fix this by using gtkmain.c gtk_synthesize_crossing_event() that is in fact
oriented to pointers.
Fixes: adba0b97 (gtkwindow: Synthesize pointer crossing events on state changes)
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5094
Instead of passing an event and figuring out coordinates from it, pass
directly the toplevel coordinates so that we can use this outside event
handling.
All callers have been updated to pass the coordinates, in practical effects
they were already based on the GtkNative.
The inner loop in gtk_paned_set_focus_child() tries to find the
topmost GtkPaned, however, if the `w` variable ends up becoming
NULL after bubbling up the entire GtkWidget hierarchy, this loop
never breaks.
Check for NULL in this loop.
Closes https://gitlab.gnome.org/GNOME/gtk/-/issues/5094
c68247f63b introduced a scroll multiplier,
intended to be significantly lower than the GTK 4.6 behavior but higher
than 1. However, it was _higher_ than 4.6, since 4.6 also had a permanent
1/10 multiplier in GDK, so the cited multiplier values were really 6.4 and
9.7.
We may have situations where velocity is 0/0, but are overshooting. Places where
this happens are mouse wheels, and continuous scroll that ended up still before
finish. In this situation we also want to run the animation for overshoot, so
check for the corresponding axes to also set up the kinetic scroll helper.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4784
The expected configurability is not going to arrive yet from compositors, and
it is precipitate for GTK to gain any configurability. We do know a factor of 1
feels way too slow, and we do know a factor of page_size * pow (2 / 3) feels way
way too fast.
With the previous multiplier, gtk4-demo at its default size had a vertical textview
factor of 64.332901, and maximized on a 1920x1080 screen a factor of 97.585365.
Pick a magic multiplier that is both significantly below these values and above 1,
and stick to it.
Future work will add the configurability of smooth scroll events where it belongs.
At that point this commit may be reverted so we don't pile up on magic numbers again.
Related: https://gitlab.gnome.org/GNOME/gtk/-/issues/4793
When widgets go mapped/unmapped, we repick but don't generate crossing
events. Since there could be stateful controllers that use those in
the previously picked widget (e.g. GtkEventControllerMotion), skipping
those breaks their state.
Ensure to send the relevant crossing events on every situation that
changes the pointer focus, so these controllers get a fair opportunity
to undo their state.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2877
Following what was done for pinch/swipe events, give hold gestures their
own distinct sequence as well. Without this it was NULL, which was already
distinct to other touchpad gestures.
This delaying of the cancel event was made to avoid intermediate cancellation
for >=2fg hold gestures followed by pinch/swipe gestures, and it worked as
long as everything was considered to have the same sequence.
Since each pinch/swipe pointer gesture now gets its own sequence, this no
longer applies, nor works. This results in zoom/rotate/swipe gestures being
stuck since the sequence for the touchpad events changes mid-gesture.
Sticking to this pattern of giving touchpad gestures their own sequence,
these hold events cannot be assumed to coalesce with other touchpad gestures,
it is better to let it propagate altogether so that both the hold gesture
and the incoming gesture trigger coherent begin and end/cancel phases.
In the worst case, this results in "::begin, ::cancel, ::begin , ..." before
triggering a touchpad gesture, but the extra begin/cancel ought to be a safe
no-op in widgets.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5003
The textbuffer test is calling into a function defined by the AT-SPI
accessibility backend. As of commit 4ddf1b70 we only build and run the
test on Linux, but the function in question isn't really
accessibility-related: it's just a serialization function.
If gtk_builder_expose_object() is called twice with the same name, it will
result in a g_critical(). This improves that situation by checking for the
object before exposing additional times.
This turns out to be handy in situations where templates are expanded
multiple times, such as application-side implementations of UI merging.
Rubberband does not work when initiated past the last row
(warning is printed "Could not start rubberbanding: No item).
Clamp y at the max height of the widgets in the listview
Rubberband does not work when initiated past the last row
(warning is printed "Could not start rubberbanding: No item).
Clamp y at the max height of the widgets in the gridview
Fixes: #3462
The function gtk_grid_view_get_items_in_rect() erroneously calculates
columns less than 0 and greater than n_columns when the user attempts
to rubberband all the way to the left or right respectively. This
causes the rubberband to persistent and creates unexpected behavior.
Limit the rows to a minimum of 0 and maximum of n_columns - 1.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3445
There's a list user_widgets that contains all of the entries and
selections during authentication. This is only freed upon
finalizing the GtkMountOperation. It's possible (and true for the
GVFS SMB implementation) that a MountOperation can have the
gtk_mount_operation_ask_password_do_gtk () function called multiple
times (i.e. bad password). The user_widgets list grows with now
invalid pointers to old widgets (causing unexpected behavior and
seg faults).
Free the user_widgets list upon dialog destruction, we don't need it
anymore.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5059
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5058
It is already explicitly assumed that anonymous authentication will
be used when available, but it is not clear to the user since neither
of the check buttons are selected. Select the Anonymous check button
by default.
When computing a transform value, there is nothing
to do, but we still need to copy the matrix from
src to dest, since it depends on the other transforms
in the array whether we are using the src or the
dest in the end.
This fixes cases like
-gtk-icon-transform: perspective(100px) matrix(1,2,...);
which would otherwise end up with a zero matrix.
