Personally I am very worried about clients doing this.
My main concern is clients acting differently than each other. This will
happen even if every one of them is using a carefully written toolkit
that implements all defined wayland behavior because they may be running
on different hosts with different versions of that toolkit. And unless
you are living in fantasy land you will know that there will be clients
that are not using perfect toolkits.
Also it makes it extremely difficult to remote to a host using a
different window system (rdp) that makes the opposite assumption,
because you have to "uncook" the events and then rely on the client
recooking them back to the same thing the use did on that host. Anybody
using NX will know this is a problem even between two X servers due to
it attempting to uncook keysyms into the scancodes used by the remote
server.
A literal interpretation of having the client do it all means you cannot
add a new type of hardware and have it emulate a mouse for software that
does not know about this new type of hardware.
In fact I think wayland should fully mark events with all kinds of
information, like "this is probably a double-click" and "the user has
dragged the mouse enough that it is not a click" and "the user has been
holding the mouse still long enough that you should do a hover event",
and everything else anybody can think of. Slight differences between
applications in deriving this information is a problem even on Windows.
It should be possible for a client to retrieve the raw events (if they
really exist at all, they won't in the rdp scenario). This mostly means
that any input processing cannot eat or delay an event, it must replace
it with something. And attaching the raw event info to it may be a good
idea.
Wayland is already "cooking" events, such as doing some of the keyboard
translation, the input methods, on-screen keyboards, the mapping of
other devices to the "seat pointer", the entire touch/gesture api, etc.
So I also see no reason to make repeat a special case.
Rui Tiago Cação Matos wrote:
Hi,
just replying to this part:
On 15 October 2013 22:05, Matthias Clasen <matthias.cla...@gmail.com> wrote:
- input tweaks like slow keys or bounce keys or hover-to-click naturally fit
in the event dispatching in the compositor
In the same spirit of having key repeat on the client side, I think
that slow, bounce and sticky keys should also be implemented by the
clients. Doing these on the compositor would in particular make things
more complex for xwayland which (I assume) should continue to provide
these features for X clients while being a regular wl_keyboard client
itself.
MouseKeys though, seems like it can be implemented in the wayland
compositor and we should probably remove the functionality from
xwayland. Hover-to-click can be done in the compositor as well.
Rui
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
