multi-touch-dev team mailing list archive

[Peter Hutterer <peter.hutterer@xxxxxxxxx>]

On Wed, Oct 06, 2010 at 03:50:38PM +0100, Mark Shuttleworth wrote:
>  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)."
> 
> ;-)

hehe, I was hoping you'd quote that. note that it's intentional that we are
as flexible as possible. what is a direction to you is a restriction to
others, possibly even to you in 5 years time.
so that "inability to make a decision" is indeed the decision that we make.

> > 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.
> 
> 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. 

I think you misunderstood what I was trying to say:
"This allows for multiple different gesture recognisers be active at the
 same time, a scenario that is quite likely to happen (I do envision GTK,
 Qt, Mozilla, etc. all wanting their own system). Whether that's a good
 thing for the UI is another matter [...]"

So while I think it is necessary to have the ability to have multiple
recognisers, for the sake of a consistent UI there should only be one
active for the basic set of gestures. Nonetheless, there will be cases where
one needs more than one.
Again, mechanism and policy are two different problem scopes.

> 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.
> 
> 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.

yup. hence the need for "common ground between desktop environments and
toolkits". Either way, we're in violent agreement here but please remember
that the rules that apply to us in the X server are different to the ones
that apply to those on the client side.

Cheers,
  Peter