[RFC] compositor: Simple key repeat implementation.

[Joakim Sindholt]

On Thu, 2012-03-08 at 16:10 +0100, Michael Hasselmann wrote:
> On Thu, 2012-03-08 at 14:52 +0100, Joakim Sindholt wrote:
> > On Wed, 2012-03-07 at 15:21 -0700, Scott Moreau wrote:
> > > There's nothing fancy about this, we just set a timer and simulate
> > > events using states 2 and 3 for repeat-up and repeat-down events.
> > 
> > Any particular reason that this is in the server and not the toolkits?
> > I'm of the persuasion that wayland should just function as a relay here.
> 
> Why? You might be convinced already, but that's not an argument in
> itself, unless you present the reasons and use-cases that convinced
> you ;-)
> 
> regards,
> Michael

With respect to having consistent applications, putting this in the
server is the correct choice. However there are many things that could
be put in the server that are in fact delegated to the toolkit, with
window decorations being the big one.

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.

- Joakim