multi-touch-dev team mailing list archive

[Chase Douglas <chase.douglas@xxxxxxxxxxxxx>]

On Thu, 2010-09-02 at 17:39 +0100, John Lea wrote:
> Hi All,
> 
> I have just published version 0.2 of the Unity Gesture UI Guidelines; it 
> is available at http://docs.google.com/View?id=dfkkjjcj_1482g457bcc7 .
> 
> There are a lot of changes so it is worth having a quick read through, 
> but the most potentially confusing modifications are to do with 
> terminology.  The interaction levels are now named Objective, 
> Application, Screen and Unity.  The term 'Chain Gestures' has also been 
> replaced with 'Compound Gestures' which hopefully better signifies that 
> the component gestures can be ordered both sequentially and in 
> parallel.  I understand that it is a pain to change terminology after we 
> have started using it in our day to day work, but if we are going to 
> make terminology changes the best time to do it is now while we are 
> still early in the development process.  From this point onwards we will 
> try to avoid making further changes to already defined terminology.

Hi John,

Great work! I have a few things I'd like to note:

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? What if inkscape understands
multitouch but not gestures? Will Unity not unlock it because inkscape
hasn't subscribed to three or four finger gestures?

My gut tells me this functionality needs to be either non-unity specific
or unity will have to relinquish control over any window that the user
requests to be non-greedy. In the former case, it still might be
difficult to get developers to adopt a framework unless more window
managers other than unity use it. Just something to think about.

2. The spec says, "Applications can also choose to only make a portion
of the window greedy." IIRC, the only way to request for input over a
portion of a window is to use XShape. XShape defines a sub-region of a
window that can accept input. I *think* that XShape is currently only
implemented on a per-window basis, not a per-client basis, so to
properly support this aspect we may need to extend XShape for per-client
regions.

The above isn't an issue with the spec of course, I just want to make it
known that it may require a bit of X development to make it work
properly.

3. The spec says that in a greedy state, a client can receive objective
and application level gestures within the greedy space. Why not within
the app window like in the non-greedy state? If the greedy space is a
sub-region of the app window, you'll be locking out the rest of the
window from receiving objective and application level gestures.

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.

Thanks for the spec update! I think it's a really great document that
will help guide us to an awesome Ubuntu UI experience!

-- Chase