multi-touch-dev team mailing list archive

["Stephen M. Webb" <stephen.webb@xxxxxxxxxxxxx>]

On Mon, 2010-10-11 at 12:45 +0200, Zeno Albisser wrote:
> 
> By having GEIS just as a transformation pipe with a raw-event-input end 
> and a gesture-event-output end i think you might be able to avoid quite 
> a lot of difficulties. The whole region subscription stuff might not be 
> necessary anymore, since a toolkit could only deliver events from the 
> region it is interested in. For us in Qt we might in that case only 
> forward the events to GEIS that we receive from within a certain region. 
> That way GEIS might not need to know about regions at all. Neither we 
> need to have a X window created before creating a GEIS instance etc. - 
> Or am I missing something?
> 
> If we further presume that the toolkit (may it be GTK, Qt or anything 
> else) manages all the desired input devices, GEIS could do pure event 
> processing and possibly wouldn't need to know about the input devices it 
> self at all.

Yes, that's exactly what I meant with my radical changes.  No regions,
no subscriptions, no enumeration of input devices in geis.  Just a set
of input cookers (which transform input formats from, say, XI2.1, to a
geis input format) and a recognizer pipeline.  Handling of input device
selection and region selection is done entirely by the client, which
already knows about these things.  An extensible recognizer pipeline and
multiple gesture recognizer instances means custom gesture in subregions
if desired but a common baseline recognizer means consistent look and
feel by default.

This design should still be able to handle the "tentative input" with
their commit/rollback semantics to allow for low-latency user feedback.

-- 
Stephen M. Webb <stephen.webb@xxxxxxxxxxxxx>
Canonical Ltd.