Touch events

[Chase Douglas]

On 02/21/2012 10:25 PM, 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.

I don't see how this resolves the game use case. Usually in a game,
every action is destructive from the start. The application will either
have to assume that wayland won't do something with the touches, or will
have to wait until the end of a touch, which just isn't feasible.

>> 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.

Why not? I can easily envision a four-touch double tap being an
environment gesture.

I can come up with many more use cases if you need. There is no way this
will work without a concept of touch ownership that is passed on to the
client applications.

-- Chase