chase.douglas at canonical.com
Tue Feb 21 12:49:26 PST 2012
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
>> 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.
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.
More information about the wayland-devel