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 <dan...@fooishbar.org> wrote: > Hi, > > On 31 July 2015 at 14:53, Carlos Garnacho <carl...@gnome.org> wrote: >> On Wed, Jul 29, 2015 at 4:52 AM, Jonas Ådahl <jad...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel