multi-touch-dev team mailing list archive

[Chase Douglas <chase.douglas@xxxxxxxxxxxxx>]

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 
> center
> 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.
> 
> Solution:
> 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
swipe immediately.

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
threshold.

P.S.: I've moved this discussion to the multi-touch-dev mailing list.

-- Chase