multi-touch-dev team mailing list archive

[Henrik Rydberg <rydberg@xxxxxxxxxxx>]

On 10/09/2010 08:04 AM, Peter Hutterer wrote:
[...]

>> Thanks for this comprised explanation. :-) It would be great to get a similar
>> explanation to the touch interface, and what one gains by moving the gesture
>> recognition to the client side. ;-)
> 
> in terms of the touch interface - will do asap but I need to get through my
> review queue first.
> 
> for moving the gestures to the client side:
> gestures are a very context-specific thing and in that article that started this
> thread, the paragraphs under "The lack of context" sum it up best: as an
> outsider you cannot know what is a gesture. So you will end up interpreting some
> things as a gesture that shouldn't, and not interpreting others that should be a
> gesture.


I agree that the meaning of a gesture is context dependent, just like a typed
word means different things in different contexts. Gesture primitives, however,
are much more like the keys themselves.

> For example, once an object is selected a number of gestures may become active
> that aren't otherwise. So on selecting an object, you need to teach the
> recogniser about these (or at least enable them), which puts you in a race
> condition because by the time the request has been forwarded to the recogniser,
> the gesture may already be over again.


To the gesture recognizer, all gesture primitives are always enabled; that is
the context-independent part of the setup. The gesture instantiator is what
would need to know about the changed gesture selection.

I can see the benefit of moving gesture instantiation closer to the client apps.
At the same time, I have yet to understand how it does not ignore some features
of the current setup. Examples would be event propagation based on gesture type,
such as the recipient of global gestures or rotation with one finger outside the
window, and the multi-user problem, such as decomposing input into a set of
hands. I know you discussed a lot of things at XDS, so maybe I am missing
something.

> Plus, the roundtrip issue of sending events to the recogniser who sends some of
> them back before you can send them to the clients.


Right, provided the recognition is placed on the client side.


> Technical reasons include the difficulty of updating the protocol if you notice
> something was missing - much harder than updating a library API.


I can agree that protocols buried deeper into a system are harder to change, but
they also provide a greater sense of consensus. Not everything is bound to
change. ;-)

Cheers,
Henrik