There are GtkGestureSingle subclasses that can be made to handle multiple
fingers (GtkGestureSingle is a subclass of GtkGesture, and not the
opposite, after all). And GtkGestureSwipe already tries to handle
GDK_TOUCHPAD_SWIPE events, except this event handler silently ignores
those.
Falling back to the GtkGesture generic handler which already
handles touchpad gesture events fixes this.
This used to do the right thing, practically ignoring those event
if they went all through the event handler, unless this motion event
triggered the cancellation of this gesture from the event handler
of another controllers.
In this case, the controller would be reset, but the motion event
would still go through its handler, setting again
current_button/sequence as the motion event has buttons in its
modifiers. This leaves GtkGestureSingle with inconsistent data
that may interfere with future runs.
https://bugzilla.gnome.org/show_bug.cgi?id=747469
Checking the return value was valid for most gestures, but
GtkGestureLongPress, where the first press triggers internally an action,
but does nothing for the sequence to be claimed/denied, FALSE was eventually
returned, and the button/sequence functions would be incorrect when
::pressed is emitted.
So check that the sequence is being handled by the gesture, this is more
desirable than the return value as it's independent of sequence state,
and still will be FALSE for the cases we want to catch here.
There are legit reasons for GtkGesture::handle_event to return FALSE,
GtkGestureSingle objects should be unsetting the current button/sequence
if that happens, in order to avoid inconsistent states.
https://bugzilla.gnome.org/show_bug.cgi?id=738591
The former can be called individually on each sequence, and the latter will
always call the former on all currently active sequences, so only implementing
resetting on cancel() works for both cases. Also, chain up on subclasses
implementing cancel.
This fixes clicking on nautilus' file list after popping up a menu, as broken
grabs are one of those situations where sequences get cancelled individually,
the "current button" wasn't properly reset, and further clicks with button != 3
were ignored.
All "exclusive" gestures listen for either pointer events, or
"pointer emulating" touch events, so only a single sequence at
a time can make these run.
That may happen separately from grab-notify, and also due to external
reasons, so ensure all sequences are cancelled if a grab is taken
in some GdkWindows that would obscure events on the controller.
