Claim the gesture when we are activating a list item.
Otherwise we end up with double activations in
columnviews: first GtkColumnViewCell handles
the event, and then GtkListItemWidget handles
it again.
Fixes: #4015
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.
Single click activation should only be done on release and not on press,
otherwise it breaks touch scrolling. Double-click activation still can be
done on press.
This matches the GtkListBox behavior as well.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3345
Move the selection changes to button release, to
avoid conflict with the drag gesture for rubberbanding.
This avoids peeking at the parent, and is generally
nicer.
Among other things, you can now shift-click to select
a range in the colors demo in gtk4-demo.
Implement the typical rubberband selection, including
autoscroll. This is only useful with multiselection,
and not very compatible with single-click-activate.
Therefore, it is not enabled by default, and needs
to be turned on explicitly.
Add a mode to GtkListItemWidget that activates on
single click and selects on hover. Make
GtkListItemManager set this on its items
when its own 'property' of the same name is set.
We only create them in root/unroot (they should be created in
appear/disappear, but that vfunc doesn't exist yet), that way we can
avoid expensive work while the widget isn't used for anything.
This way, we can ensure it's always there when we need it (before the
item gets created) and gone when we don't (if some GC language holds on
to the item after we've destroyed the widget).
Instead of 6 vfuncs, we now have 3 and rely on the factory keeping track
of what it needs to do.
We're doing lots of dancing from one object to another here, but this
will hopefully get simpler with further commits.
This splits GtkListItem into 2 parts:
1. GtkListItem
This is purely a GObject with public API for developers who want to
populate lists. There is no chance to cause conflict with GtkWidget
properties that the list implementation assumed control over and
defines a clear boundary.
2. GtkListItemWidget
The widget part of the listitem. This is not only fully in control of
the list machinery, the machinery can also use different widget
implementations for different list widgets like I inted to for
GtkColumnView.
