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 <[email protected]> Canonical Ltd. _______________________________________________ Mailing list: https://launchpad.net/~multi-touch-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~multi-touch-dev More help : https://help.launchpad.net/ListHelp
