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

[Daniel Stone]

Hi,

On 18 February 2016 at 11:57, Carlos Garnacho <carlosg at gnome.org> wrote:
> On Thu, Feb 18, 2016 at 11:03 AM, Daniel Stone <daniel at fooishbar.org> wrote:
>> 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.

Yeah, at the moment we just merge them into a single logical
wl_pointer; we don't allow them to make independent/simultaneous
motion either. So just as moving left on one touchpad and right on the
other touchpad results in no motion (or a jittering pointer), I don't
think we should aim for separate gesture streams.

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

Oh! I was interpreting that as Wayland object destruction, rather than
some kind of irreversible action inside the client.

Thanks for the clarifications.

Acked-by: Daniel Stone <daniel at fooishbar.org>

Cheers,
Daniel