multi-touch-dev team mailing list archive

[Chase Douglas <chase.douglas@xxxxxxxxxxxxx>]

On Fri, 2010-10-08 at 14:21 +0200, Henrik Rydberg wrote:
> On 10/04/2010 08:48 PM, Chase Douglas wrote:
> [...]
> 
> > When I thought about MT grabbing, I realized that grabbing really needs
> > to be done on a per-finger basis, and the client needs to decide early
> > on whether to grab the touch through the entire touch, or whether it
> > should allow events through to non-grabbing clients.
> > 
> > Imagine you perform a two finger pinch gesture and then move directly
> > into a two finger drag. If a client subscribes only to the drag gesture,
> > it will receive gesture events for the drag once grail starts to
> > recognize it. However, this breaks down when we try to involve MT grabs.
> 
> 
> Pardon me, but since the current setup works, it seems to me the complication
> comes from the notion of grabs itself, not from solving any particular problem.
> Perhaps if we go back and formulate what problem grabbing is supposed to solve,
> we can find solution that fits more naturally.

Heh, that's exactly the point. The current setup works because uTouch/X
is not feature complete yet. Grabbing is necessary for us to be able to
lock out applications from receiving three and four finger events as
specified in the Unity UI guidelines. Right now we don't support this
locking, so we can get away without thinking about grabs.

As for what the solution should look like, feel free to discuss any
issues you see. I've spent some time thinking about it over the past few
weeks, and I can't think of a better way than the passive grabbing
proposed for XI 2.1. I've not limited myself to just what's been
proposed either; originally I was thinking of a different mechanism. As
I thought about it more, I realized that it wouldn't work out, but the
XI 2.1 passive grabbing paradigm would.

> > We would need to wait through an entire touch sequence until a
> > subscribed gesture is found before we can decide whether to handle all
> > the events ourselves or replay them to other clients.
> 
> 
> This I do not understand - are we talking about gesture primitives and gestures
> being the same thing here?

Gesture primitives. I detailed this more in the other thread with a
sequence of events. If it's not clear from that, let me know.

> > What I think we'll need to do is modify grail so that it recognizes a
> > subscribed gesture very soon after a touch begins. If no gesture was
> > recognized, the touch needs to be passed through as normal MT events for
> > the remaining duration of the touch. This allows a grabbing client to
> > make a decision on whether to replay events for the touch to
> > non-grabbing clients.
> 
> 
> Well, this looks a lot like what is implemented already, except gesture
> primitives are not required to be continuous.

It should be really close to what's already implemented. We just need to
add one more criteria to each gesture primitive recognizer: that the
gesture primitive begins shortly after the touches are down.

> > This also means grail can't recognize gestures
> > based on touches that have already been disposed to pass-through status.
> 
> 
> Which breaks down as soon as we look at composite gestures...

A composite gesture will start as one gesture primitive and continue as
other primitives. The touches making up the initial gesture primitive
will not be disposed to pass-through status, so they can still be used
for the further gesture primitive continuations.

-- Chase