peter.hutterer at who-t.net
Wed Feb 22 21:41:07 PST 2012
On Tue, Feb 21, 2012 at 04:25:39PM -0500, Kristian Høgsberg wrote:
> 2012/2/21 Chase Douglas <chase.douglas at canonical.com>:
> > On 02/21/2012 09:16 PM, Kristian Høgsberg wrote:
> >> 2012/2/20 Chase Douglas <chase.douglas at 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
More information about the wayland-devel