[PATCH weston v2 1/5] protocol: Add _wl_pointer_gestures (swipe/pinch) protocol

[Carlos Garnacho]

Hey Daniel :),

I see Jonas replied, I'll try to give some more detail.

On Thu, Feb 18, 2016 at 11:03 AM, Daniel Stone <daniel at fooishbar.org> wrote:
> Hi,
>
> On 31 July 2015 at 14:53, Carlos Garnacho <carlosg at gnome.org> wrote:
>> On Wed, Jul 29, 2015 at 4:52 AM, Jonas Ådahl <jadahl at gmail.com> wrote:
>>> On Thu, Jul 23, 2015 at 07:00:27PM +0200, Carlos Garnacho wrote:
>>>> +<protocol name="pointer_gestures">
>>>> +  <interface name="_wl_pointer_gestures" version="1">
>>>> +    <description summary="touchpad gestures">
>>>> +      A global interface to provide semantic touchpad gestures for a given
>>>> +      pointer.
>>>> +
>>>> +      Two gestures are currently supported: swipe and zoom/rotate.
>>>> +      All gestures follow a three-stage cycle: begin, update, end and
>>>> +      are identified by a unique id.
>>>> +
>>>> +      Warning! The protocol described in this file is experimental. Each
>>>> +      version of this protocol should be considered incompatible with any
>>>> +      other version, and a client binding to a version different to the one
>>>> +      advertised will be terminated. Once the protocol is declared stable,
>>>> +      compatibility is guaranteed, the '_' prefix will be removed from the
>>>> +      name and the version will be reset to 1.
>>>> +    </description>
>>>> +
>>>> +    <request name="get_swipe_gesture">
>>>> +      <description summary="get swipe gesture">
>>>> +     Create a swipe gesture object. See the
>>>> +     wl_pointer_gesture_swipe interface for details.
>>>> +      </description>
>>>> +      <arg name="id" type="new_id" interface="_wl_pointer_gesture_swipe"/>
>>>> +      <arg name="pointer" type="object" interface="wl_pointer"/>
>>>> +    </request>
>>>> +
>>>> +    <request name="get_pinch_gesture">
>>>> +      <description summary="get pinch gesture">
>>>> +     Create a pinch gesture object. See the
>>>> +     wl_pointer_gesture_pinch interface for details.
>>>> +      </description>
>>>> +      <arg name="id" type="new_id" interface="_wl_pointer_gesture_pinch"/>
>>>> +      <arg name="pointer" type="object" interface="wl_pointer"/>
>>>> +    </request>
>>>> +  </interface>
>
> One suggestion I'd have is to register surfaces explicitly, i.e.:
> <request name="add_surface">
>   <description summary="register interest for gestures on a particular surface">
>     Adds the surface to the list of surfaces which will receive
> gesture events. Each surface may only be registered on one
> wl_gesture_manager object.
>   </description>
>   <arg name="surface" type="object" interface="wl_surface"/>
>   <enum name="gestures" description="gestures the client is interested in"/>
> </request>
>
>>>> +  <interface name="_wl_pointer_gesture_swipe" version="1">
>>>> +    <description summary="a swipe gesture object">
>>>> +      A swipe gesture object notifies a client about a multi-finger swipe
>>>> +      gesture detected on an indirect input device such as a touchpad.
>>>> +      The gesture is usually initiated by multiple fingers moving in the
>>>> +      same direction but once initiated the direction may change.
>>>> +      The precise conditions of when such a gesture is detected are
>>>> +      implementation-dependent.
>>>> +
>>>> +      A gesture consists of three stages: begin, update (optional) and end.
>>>> +      There cannot be multiple simultaneous pinch or swipe gestures, how
>>>> +      compositors prevent these situations is implementation-dependent.
>>>
>>> There cannot be multiple simultaneous gestures one one seat. There can
>>> be multiple gestures but that means they are on different seats.
>>
>> Right, that's the idea. On multi-seat, there would be several
>> wl_pointers, and each could be able to perform gestures individually.
>> I reworded the docs blurb to be more specific there.
>
> That works for touchpads (what I assume this was designed against),
> but breaks for multitouch touchscreens: there you could be
> pinching/zooming/scrolling/etc in multiple areas at the same time. I'd
> prefer to see the individual gestures (swipe/etc) come in as new_id
> events, which would allow multiple simultaneous gestures.

As you point out in touchscreens you could be interacting with
multiple areas at the same time, to the point that 2 nearby touches on
a same surface might be happening on different widgets, and thus those
should be interpreted separately. Only if these happened on the same
widget should be interpreted as a 2-finger gesture, but it's something
the compositor just doesn't have enough context for.

So here I'm aiming for touchpad gestures only indeed, those are
directed to a single point (the pointer position), so can be sent
as-is to the client. The approach I took in gtk+ is wrapping these
touchpad gesture events with the same GtkGestureZoom/Rotate/Swipe
gestures that interpret touchscreen events, so the client-side end
result is that it doesn't matter the device the gesture is coming
from.

But you raise an interesting point though, I may have several
touchpads (eg. wacom tablets that handle touch also appear as giant
touchpads), and I could attempt to perform gestures simultaneously.
Anyhow, I think the compositor should prevent this somehow, instead of
us allowing several logical event streams from a same wl_pointer.

>
>>>> +      A gesture may be cancelled by the compositor or the hardware.
>>>> +      Destructive actions should not be considered until the end of a
>>>> +      gesture has been received.
>>>
>>> Does this mean that a client may not destroy a gesture object after a
>>> "begin" before an "end"? Why should that not be allowed?
>>
>> As Peter said, that's rather a remark for clients, changed the wording
>> ("permanent or irreversible" instead of "destructive"), and made it
>> clear it's specific to clients.
>
> What does 'clients not should consider a destructive action ...' mean?
> Does it mean that you aren't allowed to close a client until a gesture
> has ended?

It means that they should consider the operation undoable until they
receive the end event with the cancelled flag unset. Gestures are for
example cancelled when extra fingers appear mid-gesture (eg. going
from a 3f swipe to a 4f one), in that case we'd cancel the first
gesture and begin the second, the effects of that first gesture in the
UI should be entirely reverted.

So to some extent, I guess you shouldn't be closing the client if the
cancelled gesture meant that :).

Cheers,
  Carlos