multi-touch-dev team mailing list archive

[Duncan McGreggor <duncan.mcgreggor@xxxxxxxxxxxxx>]

On 10/11/2010 08:14 AM, Duncan McGreggor wrote:
> On 10/11/2010 04:45 AM, Zeno Albisser wrote:
>>
>>  Gentlemen,
>>
>> I've gone trough the specification for GEIS 2.0. And I think the
>> specification is moving into a good direction.
>> But it seems that the previously described "radical changes" will make a
>> huge part of this document obsolete already again. As I previously
>> mentioned already, the direction described earlier in this thread sound
>> optimal to me.
>> My only concern about that whole stuff is that it might become a heavily
>> over engineered beast, if you try to make it fit every possible use case
>> already from the beginning.
> 
> I share a similar concern as Zeno has expressed. I believe that the work
> that Stephen and others are putting into this is excellent and much
> needed. Peter Hutterer's remarks at UDS have inspired us all to look
> into our API more closely and examine related research in HCI APIs.
> 
> That being said, if we try to cover every contingency for GEIS 2.0,
> we're going to have to write all of our apps this cycle against GEIS
> 1.0, 'cause 2.0 simply won't be ready in time.
> 
> I'd like to encourage a less featureful 2.0 API. We can save the rest
> for 3.0 :-)

I've just created a UDS sessions for this here:
  https://blueprints.launchpad.net/ubuntu/+spec/appdevs-dx-n-geis-roadmap

Folks can subscribe to this blueprint if they so desire.

d

>> I would for example suggest just to concentrate on touchscreen /
>> touchpad input for the moment. (Unless you already have more specific
>> internal needs of course.)
>>
>> 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?
> 
> Stephen's on holiday today, but I'm looking forward to his feedback on this.
> 
>> 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.
>>
>> I hope my input does not add too much confusion! ;-)
> 
> Not at all! I'm glad you articulated your thoughts here.
> 
> Thanks,
> 
> d
> 
>> Best Regards,
>>
>> Zeno Albisser
>>
>>
>>
>> On 10/08/2010 06:49 PM, ext Stephen M. Webb wrote:
>>> On Fri, 2010-10-08 at 09:40 -0600, Duncan McGreggor wrote:
>>>> I believe Stephen already has some changes he wants to make to this
>>>> proposed spec, so expect updates :-)
>>> I'm thinking of radical changes, in fact.  This came out of the XDS
>>> decision to move gesture recognition into the client side.
>>>
>>> Before I go to far, I want to give a brief description of what I think
>>> the 2.0 API should be like to see if this jives with everyone.
>>>
>>> Geis 2.0 will have two ends:  an input end and a recognition end.
>>>
>>> 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.
>>>
>>> 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 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.
>>>
>>> There are still some details I need to work out before I can formalize
>>> this more, but I would value some feedback on whether this is sane or
>>> not.
>>>
>>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~multi-touch-dev
>> Post to     : multi-touch-dev@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~multi-touch-dev
>> More help   : https://help.launchpad.net/ListHelp
>