multi-touch-dev team mailing list archive
Mailing list archive
Re: What's the point of timing out the recognition of drag gestures?
On 03/22/2012 01:46 PM, Daniel d'Andrada wrote:
> Example Use case (in Unity):
> 1- User lays 3 fingers over a window.
> 2- arrow handles/knobs fade in over all corners of the window and on its
> 3- User stares at those new things for a couple of seconds thinking
> "what the heck... ah! I should be able to move this window now, with my
> three fingers, as those handles seem to be indicating me!"
> 4- User starts to slide his 3 fingers, expecting the decorated window to
> follow them.
> Expected outcome:
> Window moves, following user's fingers.
> Actual outcome:
> Window stays put.
> What happens in utouch world:
> 3-fingers Touch gesture comes, causing unity to display those movement
> handles over the affected window.
> During those couple of seconds while the user was staring at those new
> graphics thinking about what to do, the tentative gesture from the
> 3-fingers drag subscription times out and is therefore rejected.
> Thus when the user finally start to slide his fingers over the
> screen/touchpad, there's no drag gesture left to send Drag gesture
> slices up to the utouch-grail client.
> One might immediately say: Ah, that's easy, just make unity code
> increase the timeout value for drag recognition.
> But what I ask is: Is there any situation where you would want such
> timeout to happen? I can't think of any. I think drag recognition should
> never timeout.
> IMHO, a drag gesture that requires fresh touch points (i.e. short
> timeout) sounds more like the requirements of a swipe/flick gesture.
> I think a drag is always a drag no matter if you started sliding your
> fingers as soon as they hit the screen/touchpad or only after some time.
> What about removing (not increasing) the timeout from drag recognition?
> The same rationale also applies to "rotation" and "pinch". But for
> "tap", timeout makes all the sense in the world, naturally.
The issue is the definition of a gesture. The unity gestures mostly are
continuous and follow your touches. However, there are some gestures,
like swipes, where we may not want to fire unless the user initiated the
I think an argument could be made that we have the defaults backwards,
that by default we should *not* have thresholds for drag, rotate, and
pinch. However, we had to have thresholds when we were still part of the
X server and could not accept/reject gestures based on client criteria.
What we need to do is add threshold and timeout configuration to the
geis api so that we can define a unity 3 drag as having no timeout and 0
P.S.: I've moved this discussion to the multi-touch-dev mailing list.