-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think I must have expressed my point poorly. If anything I was trying to use the enormity and impracticality of such an ideal solution to justify why we should not dismiss the value of multiple gesture engines working together in a friendly manor.
Permitting the forwarding of relatively unadulterated events means that a down stream engine can work nicely where it needs to support novel features. By letting the downstream engine be a client, it also eases the path to pushing features upstream for the benefit of all. I also think that if the ideal is our long-long-term goal, we stand to greatly improve the chance of success, or at least ultimate progress, by making the near term implementations useful and exciting. In short, I mostly agree with your philosophy. If anything, the only difference might be that I think its good to remember from time to time what we plan to do next and where we think this all may end up in the distant future. I should acknowledge that sometimes I get distracted thinking about the future stages too much and need to be reminded to focus on today a bit more :) Rafi On 10/07/10 12:24, Ping Cheng wrote: > Hi Rafi, > > I like your wishful thinking. It inspired me to think and to understand. > > However, there are some ideas I'd like to share which could be > different from yours. I think the key factor that made us see things a > bit differently lies in the different mindsets we have: research v.s. > industry oriented. This world needs both of those ways of thinking. > > We should not plan for an ideal solution since it doesn't exist. We > can only stage our solutions and schedule changes into the plan. > Providing a basic gesture engine within, say 6 months, is better than > letting users wait for 6 years to get a complex solution. People can > not wait that long. > > Instead of waiting for the ideal world to come, we live with this > "imperfect" world and improve ourselves. Sorry to sound like Laozi > although there is no way for me to cut that tie no matter how hard I > work on it ;-). My point is: we commit to a solution and a deadline > for our users. And we make our users happy. Then, we add more features > and improve the existing ones so we keep them happy. The world is > still not perfect. But we gained happy users. > > Does this sound too far away from your reality? > > Ping > > On Wed, Oct 6, 2010 at 11:05 AM, Rafi Rubin <[email protected]> wrote: >> >> IMHO a good (or ideal) gesture engine should be able to support complex >> gestures involving multiple input devices with varied modes of physical >> expression. And an ideal engine will also enable applications to express >> and register their desired gestures. >> >> I do think those are some lofty goals and don't expect to see such an ideal >> engine any time soon, but I think its a goal worth striving for. >> >> Perhaps it would be worthwhile to have a clear set of guidelines. Specify >> what your requirements are for a primary engine, and what secondary and >> tertiary engines should avoid breaking. At least if they want to be >> compatible with Ubuntu. Even if in the end such specs don't result in good >> competitive alternatives, they will clarify the thinking and philosophy for >> uTouch. >> >> If an ideal engine is developed, would there be any resistance from complex >> application for non-technical reasons? Would commercial applications be >> afraid of spilling proprietary IP by engaging a centralized engine? >> >> In the short run, we can't offer an ideal engine. It would be draconian to >> limit functionality of third party applications to protect our vision. >> Permitting applications to request straight up MT coordinate data (as a >> gesture or by other means), is a way to remain flexible and lower the >> barriers to adoption. >> >> As you pointed out, you can decide after the fact if the app is being clever >> or stupid. Published guidelines might help prevent such conflicts, and >> might even help the app developers realize they should use or improve >> existing engines instead of starting from scratch. >> >> (more carrot less stick) >> >> I know its unlikely, but there is a chance some of those application >> developers might even come around and contribute some of that third party >> code to the aid the rest of the community. >> >> >> Rafi > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMrgd+AAoJEPILXytRLnK2AawP/1aR0C7s73mMy3oCrxMChcXD Oo6hpsavT7P59BoUYLW/Fthc0X4kF9+G3bJi2F2gVjaQSffXQl/BLHdhLmlEE7h6 efniK73VOFI7BPEUDH+uAj+zX4Zr3PCgxLG41vJs5NqZAadCupFX+GbSocrSqYTC 0as2JFwiwMMdqBphARfpLjbZvZXZe/jUsVE4B2rO4fXEnS1SebJ1Fugp4HBFIlzs PpcT/X/npQf+e8nMW/uR5VEd4F8iome9wmaJUICeyH7KVUMU62doT5vRORrDz2El MBXoheFp4VPzCySWmoMTGakfu2r8Ci3aC1JPl6xe50Bk9ismS1YZdaMS4u9Mvums nla1pU4KfmAEYgsraXz+Xie5VGqqBUTe/KaUBTonAJq5Btu0LRBesN9yM4q74mMH ROiLGiAti0pb9D14JR3yYpQK4Y2MNvbWZbTPXbaBYRJYvHJCKUKGfp5srHbpl6DJ Gcu8dMwfPT04BkCwxhxHw/RzLgIuFct43UFYxeLgnwkEWfL1w9oqaYLKb6jA7doQ m14bjXiE97Fv6iPeSkiFuSIyxTTgDdlM8C3/EtlO511uYwu9UvHcDzF/h39xDsBh IuYWlbhfRRXv57enzAgHmJFlhidi3t16Bg2W2oT42ojAxSIAfecjXFoUT7kkVZtY AlOp88zpJ+JCD3DAb7Db =AoRJ -----END PGP SIGNATURE----- _______________________________________________ Mailing list: https://launchpad.net/~multi-touch-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~multi-touch-dev More help : https://help.launchpad.net/ListHelp
