The gtk_print_run_page_setup_dialog() function, and its asynchronous
variant, are declared in the common gtkprintoperation.h header, but
implemented in different source files depending on the platform.
We want to find focusable children, so we need to look at
the focusable property, not at can-focus. This is a change
from GTK 3, where can-focus was the correct property to
look at.
The intention of the code is to find a focusable ancestor,
so it needs to look at the focusable property, not at
can-focus. This is a change from GTK 3, where can-focus
was the correct property to look at.
Fixes: #3965
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.
We iterate here from the target widget up the toplevel checking
for the previous and new grab, there's however 2 bugs here:
- The check for is_shadowed was different to the check for was_shadowed
- The loop started with the assumption that the widgets did not hold
a grab, just to change it if the grab widget was found. (or maybe
it's the other way around? it's unclear with the differing checks
for past/present state).
Make these checks consistent, and ensure we start with the right
assumption for the past/present grabbing state, and accounting that
new/old grab widgets may or may not be part of the pick stack.
With gtk_grab_notify_foreach() just taking care of emitting crossing
notifications due to the GTK grab change, rename it to a more apt
gtk_synthesize_grab_crossing().
The _gtk_widget_grab_notify() function just (maybe) did a) reset
controllers and b) hide toplevels. The second part was a testing
remnant introduced in commit 024d832d94, not part of the original
fix.
Do the former more concisely, called from the place where we figure
out whether a widget's ability to receive events changed due to
GTK grabs. It's across those changes that we are interested in
resetting the controllers.
With the gestures being reset both ways, GtkWindowHandle (and
probably other) gestures are now able to reset after a GTK grab
takes input away (e.g. GtkMenuButton). This could be seen as
a sudden jump the next time they'd be dragged with the mouse,
as the gesture would "resume" the previous interaction.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3942
When a new sequence is added to a GtkGesture, its state is looked
in other gestures in the same group, and made to match in this
gesture. This however happened a bit too early, before the
gesture touchpoint was fully set up. As this may result in signal
emission and whatnot, it's a good idea to make it happen with a
fully set up touchpoint.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3946
Match GtkListBox, so it's possible to use the same styles for them.
Update GtkListView and GtkGridView docs to reflect that, fix a few gtk-doc
formatting leftovers along the way.
