multi-touch-dev team mailing list archive

[Rafi Rubin <rafi@xxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/06/10 18:21, Peter Hutterer wrote:
> On Wed, Oct 06, 2010 at 02:05:07PM -0400, Rafi Rubin wrote:
>>
>>
>> James Carrington wrote:
>>> From our Windows 7 application experience, I would like to echo
>>> the need for sophisticated applications needing their own gesture
>>> recognition capability and access to raw touch data.
>>>
>>>
>>> For example SpaceClaim Engineer (a multi-touch CAD app on Windows)
>>> has dozens, perhaps going on hundreds, of unique gestures it
>>> recognizes.  They also use combinations of pen & touch in
>>> innovative ways which motivates them to want raw HID data from
>>> both touch and pen
>>>
>>>
>>> There won?t be a lot of these applications, but the ones that do
>>> will really show the advantages of multi-touch (and pen) and
>>> should be supported IMHO.
>>
>> 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'm a bit behind on my paper reading, but researchers have tried this for
> quite a number of years already. Do you know of any real successes?

I do not.  More a matter of wishful thinking.  I do feel that such a language
will be an important part of an ideal engine.  Maybe the increased pressure from
the proliferation of mt hardware and applications will encourage the research.

Rafi

> 
>> 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.
>>>
>>> *From:* multi-touch-dev-bounces+james.carrington=n-trig.com@xxxxxxxxxxxxxxxxxxx [mailto:multi-touch-dev-bounces+james.carrington=n-trig.com@xxxxxxxxxxxxxxxxxxx]
>>> *On Behalf Of *Mark Shuttleworth
>>> *Sent:* Wednesday, October 06, 2010 7:51 AM
>>> *To:* Peter Hutterer
>>> *Cc:* multi-touch-dev
>>> *Subject:* Re: [Multi-touch-dev] Peter Hutterer's thoughts on MT in X
>>>
>>>
>>> On 06/10/10 02:45, Peter Hutterer wrote:
>>>
>>>    This smacks of the old X inability to make a decision and commit to a
>>>
>>>    direction.
>>>
>>>
>>> [citation needed]
>>>
>>>
>>> From http://www.faqs.org/docs/Linux-HOWTO/XWindow-Overview-HOWTO.html
>>>
>>> "One of X's fundamental tenets is "we provide mechanism, but not
>>> policy". So, while the X server provides a way (mechanism) for
>>> window manipulation, it doesn't actually say how this manipulation
>>> behaves (policy)."
>>>
>>> ;-)
>>>
>>>
>>> But I predict that sooner or later, we'll see a second and third
>>>
>>> engine emerge, maybe for an app that needs really specialised gestures.
>>
>> Competition could be a good thing if there's a deliberate effort to
>> share and work towards common interfaces and consistency where
>> possible, particularly for overlapping functionality.  It would be
>> nice to avoid holy wars that hurt ordinary users.
>>
>> 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.
> 
> I agree. Writing documentation is quite useful to oneself, often more useful
> than it is to the poor bugger who has to read it later.  Most of my
> epiphanies come from writing man pages, protocol specs and blog posts.
> 
> Cheers,
>   Peter
> 
>>> I agree, and I can think of use cases that support that, for
>>> example CAD applications.
>>>
>>> Where I disagree with your speculation is the idea that it would
>>> be a good thing to support multiple gesture engines for different
>>> tookits. By definition, a toolkit is general-purpose, and maps to
>>> a whole portfolio of apps. XUL, Qt, Gtk are examples. Having
>>> different engines there means that whole sets of apps will behave
>>> differently, depending on their toolkit. And it means that
>>> improvements, such as latency and signal processing work, are
>>> diluted across all the toolkits - bad for the user.
>>
>> Agreed.  My understanding is that QT supports using native engines
>> when available and possibly an internal engine as a fall back (is
>> that correct?)  We should encourage the other toolkits to adopt a
>> similar policy.
>>
>>> That's quite different to the idea that a CAD app might invest in
>>> some highly specialised and unique gesture processing. As soon as
>>> it's "competing toolkit engines" you're in a world of user pain.
>>
>> 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?
>>
>>> We've seen this before, and since this is a new area we can avoid
>>> it. We ship too many spelling checkers already :)
>>
>> And yet we all still make spelling mistacks.
>>
>>>
>>>
>>>    We can be very clear about this: Ubuntu won't support
>>>
>>>    multiple simultaneous competing gesture engines.
>>>
>>>
>>> How does this work out if an application decides to interpret raw touch data
>>>
>>> into gestures by itself? That would be a competing gesture engine then.
>>>
>>>
>>> If the use is defensible, encourage it, if it's not, patch it out
>>> or deprecate the app.
>>>
>>> Mark
>>
>> 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.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMrQlsAAoJEPILXytRLnK2aMgQAI6ijmfaILrbCm9iaX+kz8Db
yp6rDoV/Kov3+00RYqLi//3Q3pljpV5jh5CyBXysR7/qWWelau4U3qR8XAQhEzZz
XSKoAUuBsTldyF07ODZkSF4TTZbpqPn6Z7KOQWyXz++/jEuIUMu0TEC4Av4uJVlO
+KhRQt+9LqVrL62wCeV+OruAtZ4u0erUoX7LJDwKNTcSdVkM+hytNQKYP0HThuLO
lvNtESsgpzYqB9pkBnpcJR57HoqHHaUwTQrygkUOtYII0Xge8uQ+W5dtVb89b++g
dLXud8tD/i9CucgJMInAPxqOf1V01Fn4oUskrGt5L1EUcLTxEFAD4ka+S78LLHnw
mc6/7J+CDWOpvC84q2ZhvrioBCcN/5nuHZZ/53kejpJl8Kh8Pi+3VwQVKW9ELb+S
4oLjW7ArTsDYAZkV5VcZjianT7vUqllgoryc9DpWe7/NRutYtwCy7YIn3d5Vt0JO
6CBBvfriml0hVcixbyO6c5Y1WCBmdZPv4YCSGrZSqbq6BRIV8/pHIcFuFROimLos
g9SiLLxFznL+/E9Bn/rgCz1AlKeGqqxm1VxwGqHBchA5Pg1sHsDBaoq6PeS8bnYe
hw53rSoqPqx8qpXlik0Ungocezmj3eyFvAcoj2JoTWVu7rti5AS0tKd7mBbYPo/7
Fv0Qz3+YZXkVHUXGSlO/
=+JpA
-----END PGP SIGNATURE-----