With the exception of incoming phone call scenario, how does one go about cancelling a touch event anyways? Unless I'm wildly mistaken, this is an unlikely scenario. The way you normally cancel touch events is you touch down on a button, then move your finger off the button and lift up, but that is all handled by the application itself, not the window manager. Correct? Therefore applications should always work under the assumption that the touches will not be cancelled unless they implement cancellation support, but for the rare even that they receive the cancel event from the WM, just commit whatever actions have been completed thus far. (treat it as the fingers lifting off the screen) <div class="gmail_quote">2011/7/7 Chase Douglas <<a href="mailto:chase.douglas@canonical.com">chase.douglas@canonical.com</a>> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im">On 07/07/2011 09:52 AM, Kristian Høgsberg wrote: > 2011/7/7 Chase Douglas <<a href="mailto:chase.douglas@canonical.com">chase.douglas@canonical.com</a>>: >> On 07/07/2011 07:28 AM, Kristian Høgsberg wrote: >>> On Tue, Jul 5, 2011 at 1:08 PM, Chase Douglas >>> <<a href="mailto:chase.douglas@canonical.com">chase.douglas@canonical.com</a>> wrote: </div><div class="im">>>>> On 06/29/2011 07:54 AM, Laszlo Agocs wrote: </div><div><div></div><div class="h5">>>>>> + >>>>> +  >>>>> + <event name="touch_frame"> >>>>> + </event> >>>>> + >>>>> +  >>>>> + <event name="touch_cancel"> >>>>> + </event> >>>>> </interface> >>>> >>>> I never understood the concept behind "touch cancel". If I'm a client, >>>> I'm supposed to sit around waiting for a touch cancel event at any >>>> point? Is it bounded in time, or could I get a touch cancel event 20 >>>> seconds into a stream of motion events? I don't see a way to get around >>>> explicitly conferring whether a touch is "accepted" or "rejected" >>>> (implicitly or explicitly) at some point, which is what XInput 2.1 is >>>> aiming to do. However, the exact mechanisms may be different in Wayland >>>> since we don't have the old X cruft to deal with. >>> >>> Yes, any stream of touch event, no matter how long, can be cancelled >>> by the compositor at any time. The use cases are when the compositor >>> recognizes a global gesture (three finger pinch to go to home screen >>> or so) or if an important system event happens (incoming phone call or >>> such). >>> >>> Whether and how to undo the effects of the touch events up until the >>> cancel is an application policy decision. If you're just scrolling a >>> browser window, it probably doesn't make sense to undo the scrolling. >>> Even if you're, say, painting in a paint app, it probably makes sense >>> to just treat cancel as end and commit the paint action, provided the >>> user can just undo that if necessary. >> >> I think undoing automatically would be better, but I'm not a paint app >> developer, and it's beside the point :). >> >>> In general, undoing the touch stream is similar to undo, which most >>> apps are already handling. From an application point of view, if you >>> have to handle unowned events (that's the XI 2.1 term, right?) for a >>> small initial window (100ms, 3s or a week), you end up with the same >>> application side complexity, and I don't see what it is apps can do >>> differently once they know that the remaining event stream belongs to >>> them. >> >> Lets say the WM responds to a short flick gesture. The user performs the >> entire gesture before the WM has decided whether it matches the flick >> pattern. Now we've sent the touch stream in its entirety to the wayland >> client, and we have to cancel it after the fact. >> >> This leaves the client in a precarious situation. It has received the >> entire stream of touch events for a touch, but it doesn't yet know if >> the stream might be cancelled or not. The client may be buffering the >> application state so it can undo changes if it receives a touch cancel. >> We don't want to force it to buffer state changes forever, so we must >> provide some guidance to developers on how to handle this situation. Do >> we say that after 1 s the client can assume the touch stream is theirs? >> That's hackish and may produce annoying side effects if the machine is >> swapping and goes "dead" for a few seconds. > > The touch stream ends with either 1) all touch points up or 2) touch > cancel. If the application receives up events for corresponding to > all touch down events, the touch stream belongs to the client. </div></div>What do we do when the user performs a one finger flick and the flick hasn't been recognized until the touch end (one definition of flick is if the final velocity at touch end is above a certain threshold)? Do we withhold the touch end event from the client until we are sure? If we withhold the touch end event, we should at least send a touch update event to describe the location of the touch end event (if different than the previous event). If you do that, then the touch end event is the same as a touch ownership event, as it only conveys the fact that the client now owns the touch stream. At best we can eliminate one event, the touch ownership-like event, if the compositor is certain before the touch stream ends that the stream does not comprise a compositor gesture. The trade-off for potentially saving one event is we are forcing clients to assume a touch stream can be canceled at any time, which may be a burden for a very long touch stream. -- Chase <div><div></div><div class="h5">_______________________________________________ wayland-devel mailing list <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> </div></div></blockquote></div> -- Sincerely, Josh