Initial impressions of the gesture branch
- From: Matthias Clasen <matthias clasen gmail com>
- To: gtk-devel-list <gtk-devel-list gnome org>
- Subject: Initial impressions of the gesture branch
- Date: Mon, 31 Mar 2014 23:10:37 -0400
Here are some unsorted, initial impressions from looking over the
gesture branch. I've also tried the wip/gesture branches of eog and
evince - they work quite nicely.
The class hierarchy I see:
GtkEventController (abstract)
GtkGesture (abstract)
GtkGestureSingle (abstract)
GtkGestureDrag
GtkGestureLongPress
GtkGestureMultiPress
GtkGestureSwipe
GtkGestureRotate
GtkGestureZoom
What other uses are there for GtkEventController, if the widget api is
now using GtkGesture ? Is it worth keeping this base class around ?
It would be good to write a high-level explanation of how events are
handled now, highlighting the changes. one way to do it would be to
update the comment above gtk_main_do_event - it needs updates anyway.
Doesn't it do violence to grab semantics if the capture phase runs all
the way from the top ?
The case for ENTER/LEAVE looks at the sensitivity of the grab_widget
before propagating the event - I think the logic there needs to be
changed to always propagate, regardless of the grab_widget
sensitivity.
The long press gesture is always using the default delay - that should
probably be a property ?
The swipe gesture is a subclass of GtkGestureSingle - aren't there
two-finger swipes, or is that not a useful distinction ?
GtkPressAndHold should probably be replaced by GtkGestureLongPress.
Comparing to ClutterAction, I see ClutterPanAction and
ClutterTapAction that have no equivalent yet.
It seems slightly complicated that gtk_widget_add_gesture() takes a
GtkPropagationPhase as argument. clutter_actor_add_action doesn't have
that.
Should gtk_widget_add_gesture update the event mask ?
Does the order of event controllers in a widget matter ?
(gtk_widget_add_gesture prepends them)
It would be good to see an example of a gesture implementation that
provides feedback/updates while the gesture is in progress - e.g. drag
up from a spinbutton entry and have the spinbutton tick up while I
keep holding. Or a long press with a 'timer' animation.
What is the ideal end state for this work ? All mouse and touch events
are handled by event controllers, and there are no more
button_press/release_event handlers anywhere ?
Do we envision applications to have custom gestures ? Any plausible
examples for that ? If yes, it would be good to have an example for a
custom gesture implementation. If not, we can probably save quite a
bit of API that is only relevant for subclassing.
[Date Prev][
Date Next] [Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]