Once upon a time, there was a function called gdk_event_get_scroll_deltas().
It returned %TRUE when an event had scroll deltas and that was used as the
condition to decide whether to push scroll deltas to the scroll history,
even when the both deltas are 0 for the stop event at the end of scrolling.
When GtkScrolledWindow kinetic scrolling code was adapted for
GtkEventControllerScroll, it was replaced with a (dx != 0 && dy != 0)
check. This prevented the stop event from getting into the history, and
instead allowed non-smooth scrolling to affect the history as they have
synthetic deltas with one of the values being -1 or 1 and the other on 0.
Instead, check the direction as we already have it as a local variable.
This needs to return a boolean, also it should not call end because
that will be called anyway by Gtk+ after cancel, and this was causing
warnings due to the opacity being unset with no dragged widget set.
In the gtk-demo drag-and-drop demo i can't drag anything, all I get
is:
(gtk4-demo:358993): Gdk-CRITICAL **: 09:36:19.617: Surface 0x7e1bb0 has not been mapped in GdkSeatGrabPrepareFunc
This is because GdkX11Drag.ipc_surface is not considered mapped, even
though we called gdk_x11_surface_show() on it, because the
GDK_SURFACE_STATE_WITHDRAWN flag is still set.
I added calls to gdk_synthesize_surface_state() to match what
e.g. show_popup() and gdk_x11_toplevel_present() does.
The flowbox demo is otherwise less than useful,
if /usr/share/gnome/backgrounds isn't present.
At the same time, give the scale in the listbox
some function.
The api contract for size_allocate() vfuncs is
that they must allocate all the children that are
going to be snapshotted in snapshot(). The flowbox
size_allocate() was just bailing out when the children
request a size of 0x0, leading to an assertion in
snapshot() vfunc later. Just allocate all children
a size of 0x0 in this case.
The previous fix broke the case where we're Shift-Tabbing
from a listboxrow child to the row itself. This was causing
the widget-factory2.tab-backward test to fail. Fix it, by
grabbing the focus to the row explicitly.
If a row has content that is focus-on-click, and is set
to focus-on-click itself, then the row steals the focus
fromt he content, since it uses focus-on-click on button
release, as opposed to button press. Avoid that by
refusing to take focus if it is already on some
descendent of the row.
This was showing up in the widget-factory listbox on
page 2, where clicking on the spinbutton would briefly
put the focus on the spinbutton, only to lose it to
the row.
Change which rows in the listbox on page 2 are activatable,
and trigger a dialog. It did not really make sense that this
would happen when clicking on the spin button to focus it.
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.
