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

[Peter Hutterer]

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