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