Commit Graph

121 Commits

Author SHA1 Message Date
Carlos Garnacho
b0a23dbfbd gesture: Add grouping API
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.
2014-05-23 19:54:25 +02:00
Carlos Garnacho
6433a5452e gesture: Add gtk_gesture_set_state() helper.
This function sets the state on all sequences where it actually
can, just a helper function to avoid iterating over sequences
yourself.
2014-05-23 19:54:25 +02:00
Carlos Garnacho
72f8c673da gesture: emit the current state on ::sequence-state-changed 2014-05-23 19:54:25 +02:00
Carlos Garnacho
ae241714c4 gesture: group continue conditions together 2014-05-23 19:54:25 +02:00
Carlos Garnacho
8ebcca2ef6 gesture: return TRUE if the sequence state was already set 2014-05-23 19:54:25 +02:00
Carlos Garnacho
f3257e1a54 gesture: fix compiler warning 2014-05-23 19:54:25 +02:00
Carlos Garnacho
4570837e48 gesture: ignore events if now widget window was found 2014-05-23 19:54:25 +02:00
Carlos Garnacho
8e1d5f98de widget: Improve button press emulation on sequence denied
Ensure that state being set on pointer emulating touches actually
gets propagated properly on widgets with gestures that only handle
pointer events.
2014-05-23 19:54:24 +02:00
Carlos Garnacho
ed5d73b49a gesture: check the gesture after denying a sequence.
So the gesture emits end() timely.
2014-05-23 19:54:23 +02:00
Carlos Garnacho
03381beacc gesture: Offer always coordinates in the gesture widget coordinate space
Translate events meant for other widgets/windows, so gtk_gesture_get_point()
always returns coordinates based on the gtk_event_controller_get_widget()
allocation.
2014-05-23 19:54:23 +02:00
Carlos Garnacho
5f24d1a519 gesture: Only recognize gestures with as many interacting touches as those handled
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.
2014-05-23 19:54:23 +02:00
Carlos Garnacho
b5c319b56f gesture: Limit API calls to non-denied sequences
Gestures do track those internally, but information about those
shouldn't be leaked on calls.
2014-05-23 19:54:23 +02:00
Carlos Garnacho
2285157c7d gesture: Require BUTTON_PRESS/TOUCH_BEGIN for sequences to be initiated.
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.
2014-05-23 19:54:23 +02:00
Carlos Garnacho
d89e810bd9 gesture: Only track non denied sequences in get_last_updated_sequence() 2014-05-23 19:54:23 +02:00
Carlos Garnacho
b7435a0290 gesture: cancel all ongoing sequences on reset() 2014-05-23 19:54:23 +02:00
Carlos Garnacho
d2c9b9c2aa gesture: Skip non-device events early. 2014-05-23 19:54:23 +02:00
Carlos Garnacho
25ece22013 gesture: Add gtk_gesture_[sg]et_window()
This can be used to restrict a gesture to an specific GdkWindow,
all events will be checked to happen on/within that window.
2014-05-23 19:54:22 +02:00
Carlos Garnacho
c4944b0376 gesture: Remove the touch-only property
This is handled in GtkGestureSingle.
2014-05-23 19:54:22 +02:00
Carlos Garnacho
83dd050ab2 gesture: Add private getter to know whether a touch begin was handled
If GDK_TOUCH_BEGIN was handled/consumed for a sequence, or GDK_BUTTON_PRESS was
handled for the mouse gesture, this function will return TRUE.
2014-05-23 19:54:22 +02:00
Carlos Garnacho
a9fa0151f1 widget: Implement hierarchy-level mechanism to claim/deny sequences
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.
2014-05-23 19:54:22 +02:00
Carlos Garnacho
8f113e07fd Add GtkGesture
This a more specific abstract type that handles one or multiple
streams of pointer/touch events.
2014-05-23 19:54:21 +02:00