These will be mutually exclusive with touch events, so it won't
be possible to trigger gestures through mixed input and whatnot.
The accounting of touchpad events is slightly different, there
will be a single internal PointData struct, stored in the hashtable
with the NULL event sequence/key (same than pointer events in
this regard), just that the events stored will be GdkEventTouchpad*,
so will hold information about all fingers at once.
But this difference is just internal, the GtkGesture API doesn't
make explicit assumptions about the number of points (the closest
to a per-point query API is gtk_gesture_get_sequences()). All
signals emitted just contain the last changed GdkEventSequence,
and API takes GdkEventSequences, so everything is consistent with
sequence=NULL for touchpad events.
Along the code, we're basically asking for 1) the total count of
touchpoints, and 2) the number of active touchpoints (not denied
nor ended).
Wrap both usecases into a _gtk_gesture_get_n_physical_touchpoints(),
and replace all occurrences.
The gestures that don't want touchpad gesture events are majority,
even those that want such events will only listen to subsets (eg.
pinch, swipe,...).
So it makes sense to ignore touchpad events by default, and let
subclasses opt those in.
Add some docs/example about the possible event handling ordering issues
that may appear on GtkGesture::begin between multiple gesture groups.
Mostly relevant for state changes.
If the event triggers GtkGesture::begin, and the handler ends up resetting
the gesture (say, due to taking a grab somewhere else within the handler),
still take the event as "managed", as it actually triggered recognition,
even if just to end abruptly.
https://bugzilla.gnome.org/show_bug.cgi?id=731711
It might happen that a gesture claims a sequence before any other gesture
in its group even handled a single event from that sequence. In that case,
ensure the state is set accordingly right when the sequence is handled in
those.
The "group" gesture testcase has been updated to observe this behavior.
Event controllers now auto-attach, and the GtkCapturePhase only determines
when are events dispatched, but all controllers are managed by the widget wrt
grabs.
All callers have been updated.
This phase is meant to run in the default widget handlers, as opposed
to externally as in the bubble/capture phase. This will be most usually
the expected phase for every controller replacing code in event handlers
in GTK+, just so invocation and triggering order is kept unaltered.
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.
Make it really sure that the event is only emitted after every gesture
that consumed the button press is done with the sequence.
The event must only be emulated if a gesture in the capture phase happened
to consume the event, be cancelled, and
Sequences may be cancelled within the ::sequence-state-changed handler, which
would change the points hashtable as it's being iterated in this function. So
iterate over a list of sequences and let the hashtable change freely.
The propagation phase property/methods in GtkEventController are gone,
This is now set directly on the GtkWidget add/remove controller API,
which has been made private.
The only public bit now are the new functions gtk_gesture_attach() and
gtk_gesture_detach() that will use the private API underneath.
All callers have been updated.
If no match is found with the gesture widget when poking the event
window parents, bail out safely instead of falling in an infinite
loop. This was seen on Mutter.
This API eliminates the need for overriding
GtkWidget::sequence-state-changed virtually everywhere. Grouped
gestures share common states for a same GdkEventSequence, so the
state of sequences stay in sync across those.
Translate events meant for other widgets/windows, so gtk_gesture_get_point()
always returns coordinates based on the gtk_event_controller_get_widget()
allocation.
If a gesture has denied sequences (so those are presumably handled above/below
the widget), it shouldn't attempt to handle extra touches, even if those end
up matching the expected number of touches.
Gestures should always receive one of such events in order to be activated,
and the propagation mechanism will ensure they do so if the original event
was caught up the widget hierarchy by another gesture that is now declining
the sequence.
The policy of sequence states has been made tighter on GtkGesture,
so gestures can never return to a "none" state, nor get out of a
"denied" state, a "claimed" sequence can go "denied" though.
The helper API at the widget level will first emit
GtkWidget::sequence-state-changed on the called widget, and then
notify through the same signal to every other widget in the captured
event chain. So the effect of that signal is twofold, on one hand
it lets the original widget set the state on its attached controllers,
and on the other hand it lets the other widgets freely adapt to the
sequence state changing elsewhere in the event widget chain.
By default, that signal updates every controller on the first usecase,
and propagates the default gesture policy to every other widget in the
chain on the second. This means that, by default:
1) Sequences start out on the "none" state, and get propagated through
all the event widget chain.
2) If a widget in the chain denies the sequence, all other widgets are
unaffected.
3) If a widget in the chain claims the sequence, then:
3.1) Every widget below the claiming widget (ie. towards the event widget)
will get the sequence cancelled.
3.2) Every widget above the claiming widget that had the sequence as "none"
will remain as such, if it was claimed it will go denied, but that should
rarely happen.
This behavior can be tweaked through the GtkWidget::sequence-state-changed and
GtkGesture::event-handled vmethods, although this should be very rarely done.
