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

[Daniel Stone]

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.

>>> +      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?

Cheers,
Daniel