Hi, On 8 March 2012 18:20, Joakim Sindholt <[email protected]> wrote: > I think that wayland should be consistent across the board and act > *only* as a display server and otherwise implement only the minimum set > of features necessary for proper operation. That entails (what I think > was the original intent) only redirecting pointer input and absolutely > nothing else. > What I think is important to remember is that wayland isn't itself a > pointing device, and only really serves as a way to push buffers to a > screen. Letting toolkit developers agree on how to do things is the > default position and in this case I don't think it's warranted to > complicate the server more by making it responsible for reinterpreting > input devices past simply picking and redirecting. > > A good example of why wayland shouldn't make these decisions: there > would be no arguments over how to generate imaginary events in the > server.
The counter-argument, though, is that you'll be generating imaginary events anyway. If someone steals focus from you or the keyboard is grabbed or the compositor decides for any reason to do anything at all that affects your interpretation of the key, it'll have to synthesise a fake release to the client to avoid it repeating endlessly. That also involves creating more (not less) protocol to communicate the key repeat settings - which keys need to repeat, the delay before they should start repeating, and the rate at which they should repeat. Not to mention that it also involves adding more timestamps, whereas if the compositor handles repeating, we can just get away with serial numbers. So, I don't think pushing it to the clients simplifies anything or solves any problems, while it actually creates problems. Cheers, Daniel _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
