multi-touch-dev team mailing list archive

[Henrik Rydberg <rydberg@xxxxxxxxxxx>]

On 10/08/2010 03:47 PM, Chase Douglas wrote:
[...]

>>> Imagine you perform a two finger pinch gesture and then move directly
>>> into a two finger drag. If a client subscribes only to the drag gesture,
>>> it will receive gesture events for the drag once grail starts to
>>> recognize it. However, this breaks down when we try to involve MT grabs.
>>
>> Pardon me, but since the current setup works, it seems to me the complication
>> comes from the notion of grabs itself, not from solving any particular problem.
>> Perhaps if we go back and formulate what problem grabbing is supposed to solve,
>> we can find solution that fits more naturally.
> 
> Heh, that's exactly the point. The current setup works because uTouch/X
> is not feature complete yet. Grabbing is necessary for us to be able to
> lock out applications from receiving three and four finger events as
> specified in the Unity UI guidelines. Right now we don't support this
> locking, so we can get away without thinking about grabs.


No, grabbing is not the only solution to system-exclusive gestures. On the
contrary. The current utouch framework could easily be extended to include such
a solution, and we already discussed in detail how that could be done. I am not
saying it should be one way or the other, only that there certainly are several
possible solutions, and I believe we have yet to find the best one.

> As for what the solution should look like, feel free to discuss any
> issues you see. I've spent some time thinking about it over the past few
> weeks, and I can't think of a better way than the passive grabbing
> proposed for XI 2.1. I've not limited myself to just what's been
> proposed either; originally I was thinking of a different mechanism. As
> I thought about it more, I realized that it wouldn't work out, but the
> XI 2.1 passive grabbing paradigm would.
> 
>>> We would need to wait through an entire touch sequence until a
>>> subscribed gesture is found before we can decide whether to handle all
>>> the events ourselves or replay them to other clients.
>>
>>
>> This I do not understand - are we talking about gesture primitives and gestures
>> being the same thing here?
> 
> Gesture primitives. I detailed this more in the other thread with a
> sequence of events. If it's not clear from that, let me know.
> 
>>> What I think we'll need to do is modify grail so that it recognizes a
>>> subscribed gesture very soon after a touch begins. If no gesture was
>>> recognized, the touch needs to be passed through as normal MT events for
>>> the remaining duration of the touch. This allows a grabbing client to
>>> make a decision on whether to replay events for the touch to
>>> non-grabbing clients.
>>
>>
>> Well, this looks a lot like what is implemented already, except gesture
>> primitives are not required to be continuous.
> 
> It should be really close to what's already implemented. We just need to
> add one more criteria to each gesture primitive recognizer: that the
> gesture primitive begins shortly after the touches are down.


When I read a document, I tend to rest two fingers on the trackpad, ready to
scroll whenever needed. In effect, this means the scrolling gesture is active
all the time. Yet, the first time placed, they might rest for a long while.

In the case of two fingers which could either be considered separate touches
(different cursors for instance) or a joint gestures like drag, rotate or pinch,
the current framework uses the combination of the ability of the gesture
recognizer to separate fingers based on multi-user aspects and the ability of
the gesture instantiator to determine the gestures listened for to decide what
will happen. If a user accepts two-finger scroll, how could two fingers from the
same hand ever be interpreted as single touches in that case?

Your idea of a touch gesture would increase granularity of the gesture
emissions. A client could choose to listen to only drag and not touch, in which
case where the fingers are placed would go through as MT events (after the tap
timeout, if listened to). Every movement would however be interpreted as a drag
gesture and not show.

>>> This also means grail can't recognize gestures
>>> based on touches that have already been disposed to pass-through status.
>>
>>
>> Which breaks down as soon as we look at composite gestures...
> 
> A composite gesture will start as one gesture primitive and continue as
> other primitives. The touches making up the initial gesture primitive
> will not be disposed to pass-through status, so they can still be used
> for the further gesture primitive continuations.


However the ones being passed through could not... It's a pretty strong
restriction, don't you think?

Cheers,
Henrik