On 08/15/2013 03:52 AM, Peter Hutterer wrote:
one of the things that should be done is to figure out _where_ features such as this are going to be handled. In the compositor, the compositor's input module, on the client side, ... ? I'm trying to figure out how to handle this correctly, but don't have much to show here just yet.For example, wl_pointer only has a button event, which means that a client cannot differ between a tap and a button click. no doubt this should be in a piece of shared code, but right now it's not quite sure what can be shared where yet. Cheers, Peter
If input methods are done in the compositor, then all this sort of decoding should be done in the compositor.
1. It seems really wasteful for the input method to do all this work and not reuse it to send the events to the client.
2. Doing it in the client relies on the fantasy that two programs possibly written in different languages and toolkits, will actually translate raw evdev events identically. It is going to be really annoying if the user's attempt to configure their input devices only works in some clients, or the input method differs from clients.
3. Allow remote display to another wayland server that is using an input configuration that relies on newer or different libraries than the client has.
4. Allow remote display to RDP on Windows, where the events already resemble the translated ones. A back-translate to evdev style events seems like a kludge, and this is by far the biggest bug I have with NX where obvious things like arrow keys do not work due to a mismatch of xkb tables on each end.
5. Makes it a lot easier for one client to display on two differently-configured wayland displays at once.
In my opinion all of xkb decoding should be done in the server, and events should be enhanced with information such as "this down could be a double click" and "the user is hovering and expects a tooltip now", "this move is far enough that the user really is dragging the object", etc. I'm sure there is disagreement about this...
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
