Multitouch followup: gesture recognition?

[Simon Thum]

Am 02.04.2010 10:52, schrieb Florian Echtler:
>>>>> 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.
>>>> Which is why a declarative approach is OK for that. It's the dynamics
>>>> that make it harder. More specificially, the dynamic part of your
>>>> formalism likely needs tailored requests.
>>> The reason for this being that the special client won't be notified of
>>> property changes on other client windows, correct?
>> Not quite, the sgc could probably register for prop changes. By
>> 'dynamics' I was referring to cancelling a gesture or other gesture
>> state feedback a client may want to send. Props aren't good for that,
>> but requests are.
>> In requests, you're free to define semantics, whereas props are limited
>> and quite racy.
> OK, I see. I'll probably stay with properties for the first attempt (the
> protocol used in my userspace lib doesn't require any such realtime callbacks
> right now). I'll probably blatantly ignore _any_ performance-related
> issues in the prototype, just to get a general feel for the problem.
Not needing callbacks even in-process (where they're cheap) sounds like
an excellent precondition for such an implementation. Though I'd guess
it won't stay like that forever.

>> To me it seems sane.
>> This replication of all input is one of the reasons for the 'special' in
>> 'special gesture client'. Whatever it shall be it should probably be a
>> part of Xi2. What leads you to think the above is flawed ?
> The main reason why this code isn't yet sufficient IMHO is that I
> haven't yet found out how to get some additional data from the received
> events, particularly 
> a) which client window the event is actually targeted at and 
> b) what the position in window-relative coordinates is.
I think this is intentional. You only get 'your events'. It's possible
you need to explicitly knock up a sort-of input cc mechanism to divert
the flow as appropriate. In that case, I guess the solution would need
to be minimally intrusive to be acceptable. CC'ing input may have
security implications as well.

But as always, Peter may know something better ;)

Cheers,

Simon