Let's cross fingers and hope nobody notices. If this went unnoticed so far, likely
means this function has never been used. If any complain is raised about this, a
stub function should be added (and marked deprecated).
When the threshold-trigger-edge property was introduced in
GestureAction, it was late in the cycle and I elected to keep it
private, given the fact that nobody was subclassing GestureAction
outside of Clutter itself.
These days, people are experimenting more with the GestureAction API, so
they will need access to the various knobs that control the class
default behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=710227
Use G_GNUC_INTERNAL instead of the leading underscore, as we may make
the accessor functions public at some point. Also, clean up the
documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=710227
1ddef9576d87c98fafbcefe3108f04866630c2cd had its logic the
wrong way round, a gesture should begin as soon as the requested number
of touchpoints is reached. Correcting this fixes tap events
https://bugzilla.gnome.org/show_bug.cgi?id=700980
Export the last event received for each touch point in its entirety,
instead of duplicating ClutterEvent accessors one at a time.
examples/pan-action.c has been updated to show the type of the event
that's causing the panning.
https://bugzilla.gnome.org/show_bug.cgi?id=685737
Ensure that when cancelling a gesture, either because a callback
has returned FALSE or because clutter_gesture_action_cancel() has
been called, the array tracking touch points is emptied and a whole
new set of touch points is needed before restarting the gesture.
https://bugzilla.gnome.org/show_bug.cgi?id=685221
Let gesture subclasses override how the drag threshold should
be handled:
• CLUTTER_GESTURE_TRIGGER_NONE tells GestureAction that the gesture
must begin immediately and there's no drag limit that will cause
its cancellation;
• CLUTTER_GESTURE_TRIGGER_AFTER is the default GestureAction behaviour,
where it needs to wait until the drag threshold has been exceeded
before considering the gesture valid;
• CLUTTER_GESTURE_TRIGGER_BEFORE will make GestureAction cancel
the gesture once the drag exceed the configured threshold.
For example, ZoomAction and RotateAction could set
CLUTTER_GESTURE_TRIGGER_NONE since the use of two fingers makes the
begin of the action more self-evident, while an hypothetical Tap
gesture may use CLUTTER_GESTURE_TRIGGER_BEFORE to cancel the tap if
the pointer moves too much.
https://bugzilla.gnome.org/show_bug.cgi?id=685028
When we miss button release events (eg. when they happen outside
of our window) we must ensure that the corresponding point is
removed from the array of tracked points, otherwise GestureAction
will get very confused and will cancel all subsequent gestures.
https://bugzilla.gnome.org/show_bug.cgi?id=683471
Add some accessors to simplify common tasks for GestureAction users:
• clutter_gesture_action_get_motion_delta() to get the delta
on the X and Y axis in stage coordinates since the last motion
event, and the scalar distance travelled;
• clutter_gesture_action_get_velocity() to get an estimate of the
speed of the last motion event along the X and Y axis and as a
scalar value in pixels per millisecond.
https://bugzilla.gnome.org/show_bug.cgi?id=681648
GestureAction supports a single device/touch point. We'll need touch
events supported in Clutter before adding the ability to set required
device/touch points on gestures.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2585
The GestureAction is marked as abstract, but it has a constructor. It
should be possible to create simple gesture recognizers through signal
handling alone, so we might as well have GestureAction be a concrete
class from the start.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2585
