multi-touch-dev team mailing list archive

[Florian Echtler <floe@xxxxxxxxxxxxxx>]

Hello Stephen, here's my 2 cents:

On Fri, 2010-10-08 at 12:49 -0400, Stephen M. Webb wrote:
> The application or toolkit will receive input events from, well,
> wherever.  XI2.1 in the case of X11, or native inputs in the case of a
> framebuffer-based installation (geis should not depend in any way on X).
> To that end, the application or toolkit will need to get an input cooker
> from geis, one per input device I imagine, and feed the raw input events
> into the cooker in its event loop.  The cooker transforms the raw input
> events into internal geis input events, and may require further inputs
> such as coordinate mappings depending on the requirements.
Sounds reasonable to me, in particular if you want to achieve OS independence.

> The application or toolkit will then have to poll the geis event loop.
> This drives outstanding cooked input events through the recognizer and
> results in zero or more events being output.  The possible events
> include (1) preview events -- the so-called tentative events, (2)
> gesture events, just like in geis 1.0, (3) touch events, for touches
> that are not recognized as part of a gesture, and (4) user-defined
> events, discussed below.  The application or toolkit can do what it
> likes with these events.
I think an application should always receive the raw touches, no matter
what the recognizer does. They can still be ignored.

> I would create a default recognizer built on utouch-grail, but the next
> step (geis 2.1?) would be to provide a programmable recognizer, somewhat
> akin to the shaders available in 3D graphics rendering pipelines.
> Applications can load programmable gesture recognizers dynamically, and
> can have different recognizers for different screen regions or input
> devices.  The programmable recognizers can emit the user-defined events
> mentioned above.
Maybe one problem here: if you happen to have different applications with
different recognizers running, they would probably have to be assigned to
specific screen regions. In fact, Ive tried something similar with libTISCH,
and the OS-independent management of screen regions was quite a hassle...

Florian
-- 
0666 - Filemode of the Beast