[PATCH weston v2 3/5] compositor: Emit wl_pointer_gesture_* events on libinput gesture events

Bill Spitzak spitzak at gmail.com
Fri Jul 31 15:22:02 PDT 2015


On Thu, Jul 30, 2015 at 4:03 PM, Peter Hutterer <peter.hutterer at who-t.net>
wrote:

> On Thu, Jul 30, 2015 at 12:43:29PM -0700, Bill Spitzak wrote:
> > Okay then, but that brings me back to my original question:
> >
> > If a client does not ask for a particular gesture (by not creating the
> > protocol object that delivers that gesture's events), and the user makes
> > that gesture, does the client get anything?
> >
> > I was trying to solve a huge problem that will make everybody hate
> wayland
> > if the answer is "no", however perhaps you do have a solution to this?
>
> are you really saying that everybody* will hate wayland because a client
> may
> not react to a pinch-to-zoom gesture?
>

Only people who the bug effects, you are right.

It appears from other email that several people are aware of the problem
and have some other ideas about how to fix it. This is the discussion of
whether a device should implement swipe gestures when pinch does not work,
which then brought up the point that gestures a user learns on a swipe-only
device can break if the pinch feature is added. The last email I saw
proposed that swipe not  work unless pinch does, but that is a bad idea.

I'm thinking a solution would be to allow the driver to recognize a "new"
gesture (pinch in this case) but still check for the "old" one (swipe). It
can then "cancel" the pinch if it decides a swipe is better, rather than
have the swipe disappear just because it started out looking like the
pinch. This is quite likely a better solution than merging all gestures
into a single event type.

It looks like "cancelled" is only a feature of the wayland client api, but
it seems like it would be easy to add to libinput.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150731/a8373456/attachment.html>


More information about the wayland-devel mailing list