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