On 02/07/2011 03:35 PM, Henrik Rydberg wrote:
The issue here is how we handle the interaction between grail for
gestures and X for multitouch and pointer emulation. In my head, I
think
the easiest thing is to do what I've done with grail 1 in the
xorg-unstable ppa: add timeouts to pass events through to X for
multitouch and pointer emulation. Unfortunately, I can't think of a
simple rework that can be accomplished in two and half weeks and
gets us
any closer.
With server-side grail, there is no technical reason why gestures
cannot be emitted in-flight, i.e., even though a touch is presented
to
the application. Let's solve this on IRC and leave the poor folks in
peace.
Henrik and I had a great discussion today. I'm going to try to
summarize
the conclusions:
1. We need to have timeouts for system, or global, gestures. A system
gesture takes precedence over sending events to clients, so we need to
make a decision within a reasonable interval whether the sequence
initiates a global gesture or not. This is what is currently in grail
1.0.19 as it exists in the xorg-unstable ppa, though it also applies
the
timeouts to non-global gestures as well.
2. For non-global gestures, instead of sending either gesture events
XOR
xi 2.1 multitouch events we can send both simultaneously and have the
client sort it out. This allows us to always send xi 2.1 events and
recognize gestures at different points throughout the touch stream. I
think we will always want the xi 2.1 events to be sent first so the
client has the full context of multitouch before gesture events come
in.
I think this will be an excellent solution for grail 2 because it will
have the touch id and event ids from X to send as properties of
gesture
events. This will allow easy client xi 2.1 to gesture event matching.
Unfortunately, this will be trickier with grail 1. If we don't
manage to
get grail 2 into natty, the client may need to perform some heuristics
to match xi 2.1 event ids to gesture ids. We'll look at this more
fully
in the future.
3. The big area of confusion between Henrik and myself was whether
events can and/or should be sent to multiple windows for the same
sequence of touches. For example, in X and OS X today you can put two
fingers down and scroll in one window, lift a finger, move the other
finger to position the cursor over a different window, then place
another finger down again to scroll in the new window. This boils down
to sending events to two separate windows for the same touch, in this
case the touch that is never lifted through the process.
I thought Henrik was wanting this level of support, since it's how
things work today. However, we both agree that this is an untenable
design. Touches must only affect one window (a simplification, but
applicable here) for the duration of their lifetime.
We believe that combining 1 and 2 will allow for the use case Henrik
would like to see. I will work on implementing this in grail 1, and
Henrik will use this approach as he works on grail 2.
Thanks,
-- Chase
