New approach to multitouch using DIDs and bitmasked events

[Mohamed Ikbel Boulabiar]

I agree that providing a tool (or a middleware) for gesture and other event
arbiter/generator is more important in the current phase.
Applications take too much time to be updated (if so.) and companies should
be convinced of the usefulness of the new apis before using them. Instead of
waiting for them, tools that take input from mt devices or any other device
can become very useful to provide advanced way of control.
Think about CAD tools and the gesture engine recognizing a zoom event and
injecting keyboard/mouse input to the application. The same application
usual to the user, but advanced control of it.

ik.


On Mon, Jul 5, 2010 at 8:30 PM, Rafi Rubin <rafi at seas.upenn.edu> 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:
>>>
>>>> On Mon, 2010-07-05 at 13:20 -0400, Rafi Rubin wrote:
>>>>
>>>>> On 07/05/2010 12:54 PM, Chase Douglas wrote:
>>>>>
>>>>>> The reason we can't pass DIDs as XI1 events is because an XI1 client
>>>>>> also doesn't see "floating" input devices that aren't attached to
>>>>>> master
>>>>>> pointers. Only XI2 can see events from "floating" input devices.
>>>>>>
>>>>>
>>>>> Would vestigial valuators enable us to support XI1?  Do we care about
>>>>> XI1?
>>>>>
>>>>
>>>> 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.
>
> 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.
>
> Oh, and um, well, I do actually select text in xterms with my fingers (and
> for a while I also had paste working, but was convinced to remove 2 and 3
> finger clicks in favor of the MT protocol).
>
> Rafi
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100705/054d48e3/attachment-0001.html>