multi-touch-dev team mailing list archive

[Chase Douglas <chase.douglas@xxxxxxxxxxxxx>]

On Fri, 2010-10-08 at 14:10 +0200, Henrik Rydberg wrote:
> On 10/05/2010 03:46 PM, Chase Douglas wrote:
> [...]
> 
> > 2. Application specific gesture or non-gesture MT events are performed
> > a. A series of MT events are sent by X to the WM and other clients
> > (flagged as being grabbed by the WM for now)
> > b. WM passes MT events to grail
> > c. Grail does not recognize a gesture that WM subscribed to
> > d. Grail sends MT events back to WM
> > e. WM tells X to "replay" MT events for the touches to other clients
> > f. X tells all the client apps they may fully process MT events now
> > 
> > The issue I see with grail right now is that step c in sequence 2 is
> > indefinite in time. We need to ensure that there's a proper timeout so
> > the WM can make a decision on the grabbed events.
> 
> 
> In the sense that a multi-finger drag never terminates, this is true. By not
> listening to the drag gestures, the MT events can be let through to the client.

I'm beginning to think we need a separate gesture primitive: touch. For
example, take the Unity window movement gesture (note this is different
than what's been published in the original UI docs, it changed near
release). The user initiates the gesture with three fingers, but must
remove a finger to enter window movement mode. We don't currently have a
good primitive for this, the closest thing we can do is subscribe to all
three finger gesture events so that we pick up the three finger touch.

If we add a gesture primitive called "touch" that is active any time the
accompanying number of fingers is touching the screen, then we can use
it for state transitions like above and add the timeouts for initiation
to all the current gesture types. 

> > I think the proper grab semantics for the purposes of system-wide
> > gestures is for the WM to have a passive grab on MT devices. This grab
> > would be activated when a touch begins, and deactivated when a touch
> > ends. However, each grab would be per-touch, and the WM could choose to
> > "replay" events for any given touch to other clients. Replaying events
> > essentially means the client relinquishes the grab for that touch, and
> > all further events from that touch will not be grabbed as well.
> 
> 
> The passive grab notion fits well into reformulating what we can do today, but
> it still leaves more to wish for in terms of touches outside of the window.
> Imagine the situation where you have the index finger down on a substrate,
> moving it around, reading a map. Now you want to zoom out, so you put down the
> thumb to pinch. The thumb finger is outside the window at first, then moved
> inside as it approaches the index finger. This feels like a very natural gesture
> to me, but it does not fit into our current thinking of passive grabs.

I understand what you are going for, but I worry about ambiguity. The
second touch that occurs outside the window might be intended for a
different window. Maybe it's a different user altogether?

I wonder how often one would need to zoom like this, and not have the
area to do so with the current method? Do you have any examples where
this zooming paradigm is necessary?

Aside from necessity, I'm not sure how intuitive this zooming paradigm
would be, since most people are used to zooming in the current fashion
only. Maybe I'm wrong, but I've not used any UIs that allowed zooming as
you propose.

-- Chase