multi-touch-dev team mailing list archive

[Rafi Rubin <rafi@xxxxxxxxxxxxxx>]

-----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 <rafi@xxxxxxxxxxxxxx> 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-----