<div dir="ltr"><div><br></div>I agree that providing a tool (or a middleware) for gesture and other event arbiter/generator is more important in the current phase.<div>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.<br>
<div>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.</div><div><br></div><div>
ik.</div><div><br><br><div class="gmail_quote">On Mon, Jul 5, 2010 at 8:30 PM, Rafi Rubin <span dir="ltr"><<a href="mailto:rafi@seas.upenn.edu">rafi@seas.upenn.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On 07/05/2010 02:06 PM, Chase Douglas wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, 2010-07-05 at 13:48 -0400, Rafi Rubin wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 07/05/2010 01:31 PM, Chase Douglas wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, 2010-07-05 at 13:20 -0400, Rafi Rubin wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 07/05/2010 12:54 PM, Chase Douglas wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The reason we can't pass DIDs as XI1 events is because an XI1 client<br>
also doesn't see "floating" input devices that aren't attached to master<br>
pointers. Only XI2 can see events from "floating" input devices.<br>
</blockquote>
<br>
Would vestigial valuators enable us to support XI1? Do we care about XI1?<br>
</blockquote>
<br>
Heh, I feel like we're returning to the conversation I had with Peter<br>
about legacy client support. Essentially, you need XI2 for multitouch,<br>
and the toolkit layer should use XI2 and translate to toolkit events as<br>
required. XI1 just isn't extensible enough for multitouch.<br>
</blockquote>
<br>
Yup, I was thinking of what you said before with something watching all the MT<br>
contacts moving around and producing conventional pointer events where they are<br>
needed. It sounds like a great idea.<br>
</blockquote>
<br>
Yeah, the problem is that the X architecture really just does not allow<br>
this to happen. The *aha* moment for me was when I was reading the<br>
wikipedia article about X :). It quoted some early principles of X, one<br>
of which was:<br>
<br>
Provide mechanism rather than policy. In particular, place user<br>
interface policy in the clients' hands.<br>
<br>
Thus, it makes sense why X is architected as it is, but it also means we<br>
have to solve issues like MT pointing above X itself.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
However, it is yet another obstacle in the path of getting MT to the X desktop.<br>
When you say toolkit, I hope you mean just some separate piece of code, and<br>
not requiring gtk/qt to get conventional pointer events. I'd hate to loose<br>
support for some real legacy apps (which I actually use for my work), where it<br>
really is standard X events or nothing (programs written in straight xlib,<br>
statically compiled, obscure toolkits, etc).<br>
</blockquote>
<br>
I think the real solution is getting the MT to pointer translation in<br>
all the toolkits. If you build your programs right, they shouldn't be<br>
statically linked to toolkits. A toolkit upgrade should just magically<br>
make things work in older applications.<br>
<br>
Now, if you've really written stuff in xlib, then you'll have to fix it<br>
up manually. How many applications are really written in xlib though?<br>
</blockquote>
<br></div></div>
Enough.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br><font color="#888888">
<br>
Rafi</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
<a href="mailto:xorg-devel@lists.x.org" target="_blank">xorg-devel@lists.x.org</a>: X.Org development<br>
Archives: <a href="http://lists.x.org/archives/xorg-devel" target="_blank">http://lists.x.org/archives/xorg-devel</a><br>
Info: <a href="http://lists.x.org/mailman/listinfo/xorg-devel" target="_blank">http://lists.x.org/mailman/listinfo/xorg-devel</a><br>
</div></div></blockquote></div><br></div></div></div>