multi-touch-dev team mailing list archive

[Chase Douglas <chase.douglas@xxxxxxxxxxxxx>]

On Tue, 2010-09-07 at 10:26 +0100, John Lea wrote:
> On 02/09/10 21:32, Chase Douglas wrote:
> > 1. The spec says, "Performing the 'greedy' trigger gesture on top of an
> > application that does not support a greedy state will produce no
> > effect." How will this be determined?
> 
> If the application does not have a greedy state nothing will happen in 
> response to a user performing the greedy gesture over the applicaiton.  
> This is simply the null case; the greedy gesture has no effect on 
> applications that do not specifically support greedy interaction.
> 
> > What if inkscape understands
> > multitouch but not gestures? Will Unity not unlock it because inkscape
> > hasn't subscribed to three or four finger gestures?
> >    
> 
> If inkscape has a greedy state, the greedy gesture will toggle the 
> greedy state on or off.  If inkscape does not have a greedy state it 
> will be limited to only receiving one and two finger multi-touch input 
> and one and two finger gestures.
> 
> I'm unsure about your comment regarding inkscape supporting only 
> multi-touch but not gestures - I think we will want inkscape to support 
> gestures for moving the view port, resizing and rotating objects, 
> etc...?  For an application to officially work and comply with the Unity 
> Touch platform it has to support gestures.  I can see that some 
> applications may make use of gestures without using multi-touch but I 
> can't see it happening the other way around.   However I may be wrong, 
> are there any specific use cases you have in mind?
> 
> Also see section 3.2.4 on protected gestures for some more info.

I think there is a very good possibility that some applications will
support multitouch without gestures. Multitouch input is the bare-metal
approach. In the long term, we want people to be using our gesture
engine when it is useful, but what happens if an application wants to
handle gestures in its own way? I'm really thinking of the 1% of
applications no one thinks about when they make their toolkits and
libraries. I don't want to harm their usability, nor users' patience,
when certain applications are broken when run on Ubuntu.

This is something we can leave for later though. No one really supports
multitouch at an application level yet, so we shouldn't be breaking
anything.

> > 4. I worry about the undo gesture and it's implementation/usage. Why not
> > just queue up multitouch events while a three-finger hold is being
> > performed, and only sending them to the application when the touches are
> > determined not to be a greedy trigger? This would remove the requirement
> > for a drawing application to be gesture aware.
> >    
> 
> This would add user visible latency which we are trying to avoid at all 
> costs.  Low latency and perceived responsiveness are really important to 
> the user experience.

Latency is an issue, but the semantics of this approach puts a lot on
the plate of developers of applications. They now have to add a buffer
to maintain undo state for multitouch. It shouldn't be integrated with
the normal undo state because then a user might accidentally redo the
three-finger hold. Or worse, if a user has undone a few steps, then does
a three-finger hold, the undone steps will be overwritten by the hold
gesture events.

We have managed to be very responsive to multitouch input when
recognizing gestures. I think we can be just as responsive when
recognizing a hold without needing to use undo events. Would you be
amenable to trying to support reserved gestures without any undo events,
and then adding undo events back in if it doesn't work?

What I'm afraid of with undo and the greedy state enforcement is that
application developers will see things work fine on other distros and
either not care about Ubuntu or, even worse, paint ubuntu in a bad light
because we are breaking their applications. Right or wrong, there are
many people out there who do not believe we have any right to set
standards because we don't post them to freedesktop.org. We want to show
them that we have great ideas and make them salivate at the opportunity
to support gestures in their applications. Breaking their current
implementations and forcing them to write a lot of new code just so it
works right in Ubuntu may push them away instead.

> Regarding the undo option in general, it is needed so that there is 
> always a simple way to revert mistakes like pressing 'delete' instead of 
> 'copy' in a touchpoint menu.

I'm all for having an undo gesture. The problem is when you force
developers to support the undo gesture or else their apps will break.

-- Chase