multi-touch-dev team mailing list archive

[Peter Hutterer <peter.hutterer@xxxxxxxxx>]

On Fri, Oct 15, 2010 at 03:56:11PM -0400, Chase Douglas wrote:
> 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.

ah, ok. yikes to the user interface, but from a technical perspective that's
possible. we have something like this in the core protocol with the
GrabNotify enter/leave events. something similar can be introduced, though I
need to look at the exact semantics, it's hard to figure out which
touchpoint to grab if you don't have the sequence number.
 
> 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.

that's quite similar to enter/leave events too :)

> 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.

yeah, I'm actually starting to slowly understand the bits...

Cheers,
  Peter