Hi, On 18 February 2016 at 11:57, Carlos Garnacho <[email protected]> wrote: > On Thu, Feb 18, 2016 at 11:03 AM, Daniel Stone <[email protected]> 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 <[email protected]> Cheers, Daniel _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
