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 _______________________________________________ Mailing list: https://launchpad.net/~multi-touch-dev Post to : multi-touch-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~multi-touch-dev More help : https://help.launchpad.net/ListHelp
