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

[Bill Spitzak]

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?

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150730/2a3674a9/attachment.html>