Hi, On Thu, Dec 23, 2010 at 02:28:51PM +0100, Denis Dzyubenko wrote: > On 23 December 2010 12:44, Daniel Stone <[email protected]> wrote: > > It's not really cancelled though. > > > > The finger has been lifted, so the touch has _physically_ finished, but > > the point of the event is to let you know that, while this has happened, > > you may still become the owner of this touch sequence in the future. > > > > Do you have a pointer to the other API? > > ah I see, I haven't read the new spec about TouchPendingFinish hence > my confusion. > > I was talking about a different concept - cancelling a touch sequence > when for example an input device changes - for example when the user > presses a key on the keyboard or window is hidden etc. As far as I > know iOS have that feature - touch is cancelled when hardware key to > switch to another app is pressed. But most importantly javascript > touch api have TouchCancel with similar semantics. In Qt we were > thinking to add TouchCancel event as well - in our case I was thinking > to send TouchCancel whenever we get SlaveSwitch event while the user > is touching the screen.
The spec allows anyone to spike a touch by accepting it and then just throwing all the events on the floor. So I'm not sure if a Cancel would be strictly required, but would be a fairly trivial addition (another AllowEvents flag). How would you envision this being used - only the owner being allowed to cancel touches, or anyone? > I guess I need to read the whole thread first, as right now I don't > see a need for TouchPendingFinish. Well, it allows you to see finger up/down state, rather than thinking the finger's been down until you gain ownership, at which stage it's been immediately lifted from the screen. One usecase where this is crucial would be for a drawing app where airbrush pressure/paint opacity is defined by the length of time your finger's been on the screen. Cheers, Daniel
signature.asc
Description: Digital signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
