New approach to multitouch using DIDs and bitmasked events

[Chase Douglas]

On Mon, 2010-07-05 at 14:30 -0400, Rafi Rubin wrote:
> On 07/05/2010 02:06 PM, Chase Douglas wrote:
> > On Mon, 2010-07-05 at 13:48 -0400, Rafi Rubin wrote:
> >> On 07/05/2010 01:31 PM, Chase Douglas wrote:
> >>> Heh, I feel like we're returning to the conversation I had with Peter
> >>> about legacy client support. Essentially, you need XI2 for multitouch,
> >>> and the toolkit layer should use XI2 and translate to toolkit events as
> >>> required. XI1 just isn't extensible enough for multitouch.
> >>
> >> Yup, I was thinking of what you said before with something watching all the MT
> >> contacts moving around and producing conventional pointer events where they are
> >> needed.  It sounds like a great idea.
> >
> > Yeah, the problem is that the X architecture really just does not allow
> > this to happen. The *aha* moment for me was when I was reading the
> > wikipedia article about X :). It quoted some early principles of X, one
> > of which was:
> >
> > Provide mechanism rather than policy. In particular, place user
> > interface policy in the clients' hands.
> >
> > Thus, it makes sense why X is architected as it is, but it also means we
> > have to solve issues like MT pointing above X itself.
> >
> >> However, it is yet another obstacle in the path of getting MT to the X desktop.
> >>    When you say toolkit, I hope you mean just some separate piece of code, and
> >> not requiring gtk/qt to get conventional pointer events.  I'd hate to loose
> >> support for some real legacy apps (which I actually use for my work), where it
> >> really is standard X events or nothing (programs written in straight xlib,
> >> statically compiled, obscure toolkits, etc).
> >
> > I think the real solution is getting the MT to pointer translation in
> > all the toolkits. If you build your programs right, they shouldn't be
> > statically linked to toolkits. A toolkit upgrade should just magically
> > make things work in older applications.
> >
> > Now, if you've really written stuff in xlib, then you'll have to fix it
> > up manually. How many applications are really written in xlib though?
> 
> Enough.
> 
> I take it you aren't stuck with commercial tools.  My lab uses various FPGA CAD 
> tools which are maintained conservatively, ie if they use a toolkit that does 
> eventually support MT->conventional, then I'd still expect it to take a couple 
> years (optimistically) to see the tk fixes percolate back to my desktop.

If you fix tk to understand multitouch (at least to translate MT events
into a single pointer), then you should be able to just drop the new tk
dynamic library onto your system and everything should work.

If they statically built in tk, then that's really their problem, and
there's nothing you can do to fx it.

I don't think fixing toolkits for this will be very difficult. I think
Qt has already started. They will translate Qt touch into traditional Qt
pointer events by default unless the application specifies otherwise. I
think that's what I read somewhere recently, I could be wrong.

> I also work with academic tools, which were started in the early/mid 90's that 
> are written in xlib.  As yes its nice to examine route by tapping the wires to 
> follow a path.  While I could rewrite that code, its a pretty simple user 
> interface that's actually well written.  Switching to a tk would probably result 
> in larger and more complex code.

I don't mean to be a bear, but at some point you just can't expect
things written 15 years ago to *just work* with the latest technology
paradigms.

-- Chase