Multitouch followup: gesture recognition?

[Matt Dew]

Hi Florian,
     Can you point me to any arch stuff you've been reading?  I'm
trying to organize X documentation and wanna get everything possible
that's useful to folks.

thanks,
Matt

On Mon, Mar 29, 2010 at 4:08 PM, Florian Echtler <floe at butterbrot.org> wrote:
> Hi again, I've been reading some background stuff on the X architecture,
> so maybe I now have a better understanding of what we are actually
> talking about:
>
>> > On one hand, I agree. But I believe that this problem is exactly what my
>> > formalism solves. By a) allowing applications to customize gestures and
>> > b) restricting them to certain screen regions (*), this isn't a
>> > contradiction anymore. E.g. what's a zoom gesture to the first app on
>> Which of course means the extension needs to transport the necessary
>> information, or describe other means of transport (e.g. the props I
>> mentioned, though as Peter pointed out, they're not good for live
>> communication).
>> This seems essential to your approach, so the feasibility of a server
>> extension (oranything else, but a extension incurs overhead) depends a
>> fair bit on the dynamics of your gesture customization.
> Just specifying what gestures a specific window would be interested in
> wouldn't usually be "live", would it? That's something defined at
> creation time and maybe changed occasionally over the lifetime, but not
> constantly.
>
>> > (*) whether these should be XWindows or something different, I don't
>> > know yet. Is there an extension that allows arbitrary shapes for
>> > XWindow objects, particularly with respect to input capture?
>> the Shape extension does that.
>> Yes, except you don't want to use it, because it would throw in far
>> too many round trips, some of which might be delayed for ridiculously
>> long periods of time, even while new events continue to be delivered.
>> So, you basically want to keep it all in-client unless it's absolutely
>> strictly necessary to do otherwise.
> Hm, this might be a problem in the long run. The classical tricks for
> dealing with non-rectangular UI objects (capturing and bubbling)
> probably are not going to work here, as gestures can't easily be split
> back into discrete input events.
>
>> > Let me try to summarize the possible approaches:
>> >
>> > 1. a pure userspace library which just converts gestures locally for one
>> > specific client without knowledge of others (this is more or less what
>> > Qt or libTISCH do right now, though in different ways)
>> >
>> > 2. a special client like a WM which intercepts input events and passes
>> > additional gesture events to other clients (possible, but with some
>> > caveats I haven't yet understood fully)
>> >
>> > 3. a separate server extension in its own right (possible, also with
>> > some potential traps)
>> >
>> > 4. a patch to libXi using the X Generic Event Extension (same as 3, but
>> > fastest to hack together and doesn't require any changes to the server.)
>> >
>> > Would you agree with that summary?
>> I don't get what 4 might be. 2 and 3 aren't really alternatives, but
>> different aspects of a server-side implementation. The special client
>> can make the server deliver events, it can't do that itself. So it needs
>> an appropriate own server extension or additional Xinput requests to
>> facilitate delivery. Which you want libXi wrappers for.
>>
>> So whether a special client detects gestures or the server itself, the
>> server needs to deliver events, and the client needs to be able to
>> receive them. This is where XGE and libXi kick in.
> Okay, it seems I'm slowly getting it. Please have a look at the attached
> PDF - this should illustrate the combination of 2/4, correct? (the
> normal Xinput events should probably be duplicated to the clients in the
> classical manner).
>
> Yours, Florian
> --
> 0666 - Filemode of the Beast
>
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
>