On Tue, Feb 21, 2012 at 04:25:39PM -0500, Kristian Høgsberg wrote: > 2012/2/21 Chase Douglas <chase.doug...@canonical.com>: > > On 02/21/2012 09:16 PM, Kristian Høgsberg wrote: > >> 2012/2/20 Chase Douglas <chase.doug...@canonical.com>: > >>> On 02/17/2012 06:01 PM, Kristian Høgsberg wrote: > >>>> - input protocol restructuring: break up events into wl_pointer > >>>> (enter/leave/motion/button/axis events, set_pointer_surface request), > >>>> wl_keyboard (enter/leave/key events... what else... unicode event, > >>>> set_map request? pending kb work), and wl_touch (down/up/motion/cancel > >>>> events) interfaces > >>> > >>> [snip] > >>> > >>> So the client window will receive touch events without delay, but may > >>> receive a cancel? I am in favor of this approach, but you need to add a > >>> way to tell the window when the window manager has "rejected" a touch > >>> sequence as well. Otherwise the client will never know when they can > >>> perform destructive operations with it. > >> > >> No, we don't need that. Don't do destructive operations on something > >> that could be the first half on a globall gesture. If you need to > >> know for sure that nobody is going to take over the events, wait until > >> the touch session is over (all touch points up, none cancelled). > > > > That doesn't make any sense. What if I'm playing a game? Latency > > matters, and I need to know that the touches are mine early on. In the > > case of a game, the environment should leave touches alone and > > immediately tell the game that the touches are owned by it. > > I didn't say that applications always have to wait for touch end. > Just that if you're doing something irrevocable like, sending an email > or formatting your floppy, you don't want to trigger on something that > could be part of a global gesture. Like touch down, then move. You > need to wait for touch end in that case.
> On the other hand, if you're scrolling in your web browser or moving > around in a game, you just assume you own the events you get and > scroll/move around. If later in that touch session, you get the > cancel event, you can just leave the web page/game where you > scrolled/moved to. Or you can undo what you did, for example, if you > scribbled in a paint app as part of the global gesture. Because you > have to be able to do that anyway. > > > Touches are used for much more than just button tapping, and waiting > > until a touch is lifted to do anything won't work. > > > > Another reason this won't work is if your environment wants to recognize > > a double-tap sequence. The first tap will end, at which point the > > wayland application will attempt to use it. But a second tap comes along > > and the environment performs an action. > > This doesn't seem like a valid use case. Quote from above "you need to wait for a touch end in that case". How will a client know what touch sequence _could_ be a global gesture? How long after the touch end will I need to wait to make sure this wasn't a gesture used by the environment? Surface-local coordinates and the fat-finger problem may cause a double-tap to happen in two different surfaces. Can the compositor cancel completed sequences? Cheers, Peter _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
