MPX and multitouch

[Peter Clifton]

On Thu, 2008-05-15 at 00:00 +0900, Jordi Polo wrote:
> 
> I have been thinking about an architecture for gestures etc. And it is
> difficult to make it out of the toolkits. 
> 
> Basically, the toolkits already have an event loop where they take
> events from X. 
> It is easy to implement mouse gestures for simple and multi pointers
> there. 
> multitouch gestures, they much more difficult but I don't see good
> reasons to move them outside that even loop.

libstroke works by having you pass coordinates from the mouse events to
libstroke:

stroke_record (int x, int y);

I'd suggest that the library should concentrate on the processing logic
required to recognise gestures from an abstract representation of the
motion paths and event sequences returned.

It is those processes / heuristics which must ideally be consistent
across the platform. I don't know what information they need for the
multi-touch case, whether it should be real-time updated, or if various
touch vs. time paths can be sent and post-processed.

Beyond this, there will need to be toolkit (or application) dependant
ways to hook into the X events, and choose whether to pass them on or
absorb them.

I'm afraid I'm not familiar with multi-touch gestures. In gEDA/gschem,
libstroke is used and bound to a particular mouse button, so gEDA
explicitly passes motion events to libstroke for analysis, thus there is
no conflict between events which might make up a gesture, and other
actions tied to that mouse button.

> Also, I don't even know how to do it. Having a library that intercepts
> mouse events process them and send their events?
> And toolkits will receive mouse events and a delayed (processing)
> gesture event and they should figure out is the same thing? or that
> library will filter the mouse events ? is it possible? will toolkits
> use it?

Given a touch-screen device.. I guess it will take time to determine
whether a sequence of events is a tap, or a particular gesture.

Whether tool-kits will use it.. pass. It could be an input module or
similar, setup for a particular hardware device, in which case -
"perhaps", but I think there is another useful case, where applications
may want to use it, or at least control its behaviour.

Best wishes,

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)