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

[Peter Hutterer]

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?

Cheers,
   Peter

* generally, using "everybody" or "nobody" in a context like this
 disqualifies you immediately from the discussion, because I only need to
 find one single person to invalidate your whole statement.


> On Wed, Jul 29, 2015 at 7:54 PM, Peter Hutterer <peter.hutterer at who-t.net>
> wrote:
> 
> > On Thu, Jul 30, 2015 at 10:10:45AM +0800, Jonas Ådahl wrote:
> > > On Wed, Jul 29, 2015 at 06:38:10PM -0700, Bill Spitzak wrote:
> > > > On Wed, Jul 29, 2015 at 6:02 PM, Jonas Ådahl <jadahl at gmail.com> wrote:
> > > >
> > > > >
> > > > > We are not going to just provide libinput events via Wayland. It
> > simply
> > > > > doesn't work. Also the Wayland protocol is different and needs to be
> > > > > different because it has to deal with protocol objects, destruction
> > etc.
> > > > >
> > > >
> > > > What I meant is that there would be a wayland protocol object (perhaps
> > > > wl_pointer_gestures) and it would deliver a wayland-style event
> > > > (wl_gesture_event), but the contents of the event would be a copy of
> > the
> > > > libinput_gesture_event fields, including the enumeration saying what
> > > > gesture it is and whether it is a begin or end. It seems that the
> > current
> > > > design means that every time a new gesture is added to libinput, the
> > > > wayland server will need to be rewritten to pass that new event
> > through,
> > > > and so would every intermediate library such as toolkits. Also it is
> > > > producing a lot of code bloat (every new method and protocol object and
> > > > event adds a fairly large table to the api library, especially
> > libraries
> > > > written for languages other than C) and the possibilities of mistakes..
> > >
> > > libinput is an implementation detail in a potential compositor. Some
> > > compositors may not want to use libinput. Some compositors may not have
> > > any use for it because they are purely remote desktop capable
> > > compositors. I don't think it is a good idea to just forward libinput
> > > evens partly for this reason. Another reason is that the protocol would
> > > not be properly versioned. There would be no way for the client to know
> > > what version would emit what events. To make it versioned, the protocol
> > > would be bumped to "synchronize" with libinput versions and somehow copy
> > > this version separation in the input layer. Another reason is that it is
> > > not possible "just copy" the fields since the types are incompatible.
> > > Another reason is that libinput events are extendable. A swipe gesture
> > > has different fields than a pinch gesture. A potential protocol event
> > > would need to contain all potential fields and only a few would be valid
> > > for any event, without the possibility to specify this in the protocol.
> > > Introducing new types of gestures would not work either, since they'd
> > > most likely contain new fields, and we'd need to update the protcol
> > > anyway.
> >
> > not that I think this needs to be said, but for the archives: fully agree
> > with Jonas.
> >
> > Cheers,
> >    Peter
> >