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 _______________________________________________ Mailing list: https://launchpad.net/~multi-touch-dev Post to : multi-touch-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~multi-touch-dev More help : https://help.launchpad.net/ListHelp
