Another approach to multitouch handling

[Rafi Rubin]

Some more targeted comments.

>          * Confines multitouch to a single client/Window: This is a well
>          known problem, to my knowledge only done to have proper
>          interaction with the paired keyboard.

There are pointer specific reasons that you might want to keep a stray finger 
tied to the group.  Imagine you've got a grip on an object in blender and a 
couple fingers stray off the edge of the window, they are still a part of the 
action and you don't want to "drop the ball" (bad joke not entirely unintentional).

>          * Exposes TrackingID right up to the client. This is an
>          implementation detail, and it's sometimes even made up,
>          depending on the hardware.

I agree the tracking should be annotated with source and confidence in the 
quality.  That doesn't mean we shouldn't track and cluster early, clients that 
know better should be able to ignore that tracking, but optimize for the common 
case and let more typical applications use generic tracking data.

>          * Makes it harder to toolkits to abstract the proper bits. I've
>          myself ported GTK+ to use XI2, and there's a lot of code to keep
>          track of (implicit) grabs, window under pointer and such, and
>          quite some other GTK+ features depending on that (::grab-broken
>          signal, synthesizing crossing events with
>          client-side-windows, ...). All that infrastructure would need to
>          be duplicated, instead of using well-tested code paths.

For these questions, I don't think you should special case at all.  Just treat 
grabs, focus, etc like a conventional pointer.

>          * Makes development harder. People developing applications with
>          multitouch in mind are required to have specialized hardware for
>          testing, this is key in short term adoption. Having multitouch
>          devices behaving as close as possible to multiple pointers would
>          enable developers to do basic testing with some spare mice.

I agree.  We should get together a virtual device that works with multiple live 
pointing devices and possibly even play back independently recorded input 
streams.  (Such a tool may also be valuable to regression testing).

>          * Potentially requires a switch in the future. Most likely, X
>          wants touchpoints to resemble pointers for most things (position
>          querying and such), so toolkits and clients will be in moving
>          grounds if multitouch is adopted too early.

Lets settle on the fundamentals, then if we change the core a bit, it should 
only be a slight mod to a thin layer.


Rafi