multi-touch-dev team mailing list archive

[Chase Douglas <chase.douglas@xxxxxxxxxxxxx>]

On Fri, 2010-10-15 at 19:56 +0200, Henrik Rydberg wrote:
> On 10/15/2010 06:12 PM, Chase Douglas wrote:
> > On Fri, 2010-10-15 at 17:23 +0200, Henrik Rydberg wrote:
> >> This thread, as well as talking some more with Peter, makes me think we are
> >> pretty close. The things I see we need to do is:
> > 
> > Hrm, based on my understanding of things, I think you are venturing
> > further apart from me, and what I thought Peter was thinking too :).

Henrik and I had a chat to try to resolve some of our issues more
expediently. I've left comments on what we discussed. With some changes,
I think we're in agreement on how to try to implement MT grabs.

[...]

> >> 2. Add the ability to split touches in XI2.1
> >>
> >> The passive grab mechanism needs to be able to gracefully handle consumption of
> >> touches, such that touch-up and touch-down events are inserted appropriately if
> >> the consumer of a touch changes.
> > 
> > Doesn't this just open up the can of worms I described above?
>
> Yep. Didn't you just ignore the problem by enforcing a certain policy for all
> gesture applications? ;-)

Henrik's goals are to be able to transition from less fingers to more
fingers to trigger a gesture that didn't exist before. So for example,
you may have one finger down dragging an object, and then you put two
more fingers down and start to move the window. This requires the WM to
grab all three touches, including grabbing back the one sent to the
client used to drag the object.

One potential way to do this may be a transition state when a differing
number of fingers is touching in a window than before. Like Device
Change Events (DCE), we could send a Touch Change Event (TCE). The TCE
would indicate which touches are available now.

When a TCE occurs, the passively grabbing client receives the grabs back
for all the touches in the window. The client can then choose to replay
or thaw events (or consume events syncronously) per touch once again.

Assuming tentative events, non-grabbing clients would also receive TCEs
detailing all the touches in the window. This would be their
notification that touches may no longer be theirs anymore. This also
means that a client may be able to handle a touch that the grabbing
client previously consumed.

This is a compromise between only allowing for a thaw or replay one for
the lifetime of a touch vs continuous control over every event by the
grabbing client for the lifetime of a touch.

> >> 3. Skip the tentative events in XI2.1
> >>
> >> From Peter's explanation, it seems the original reason for this was to not run
> >> out of buffer space. Since the semantics is still unclear (just follow this
> >> thread for an example), it is probably best pushed to future expansions.
> > 
> > The semantics of tentative events seems clear to me, what issues do you
> > see? In fact, we haven't really discussed the alternative of queuing up
> > grabbed events for serial replaying, but I think that has even more
> > issues because of event ordering. If you go with tentative events, you
> > can send all the events in the correct order the first time. If you
> > queue up events, you have to worry about how device change events (known
> > elsewhere as DCEs) in the XI 2 spec are handled.
> 
> 
> From what I gather, tentative events are passed during the time when an event is
> neither replayed nor consumed. For gestures, this is exactly the time when
> nothing at all should happen. If the gesture is accepted, the action will be
> controlled by the entity detecting the gesture, and it is up to that entity to
> make sure some kind of feedback is given. Nota bene, the *gesture* may very well
> be tentative at this stage. If the gesture is cancelled, the real events will be
> replayed and things will continue as normal. Thus, I see no reason at all to
> introduce tentative events.

One example where a non-grabbing client would want to provide feedback
is to allow for object highlighting while the grabbing client is waiting
for a gesture recognition timeout. Even if there's delay in the
non-grabbing client for performing an action, highlighting can reduce
perceived delay to the user.

During our discussion, Henrik wasn't 100% convinced of this approach,
but couldn't find a good way around it at the time. Tentative grab
events are still not set in stone, but I think will be part of an
initial attempt at XI 2.1.

I think after our discussion that Henrik and I are much closer in
agreement on how to initially proceed with MT grabbing in X.

-- Chase