multi-touch-dev team mailing list archive

[Ping Cheng <pinglinux@xxxxxxxxx>]

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