<html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-text-html" lang="x-unicode"> On 20/12/13 17:24, Quentin Glidic wrote: <div class="moz-cite-prefix"> <blockquote type="cite">The first important point is here: the client only binds an *action*. The action is a describing string and does not leak the key which is bound. There would be a set of standard actions, some vendors ones, and user custom ones (which application would have to support too with a custom setting). </blockquote> I really like this idea. KDE applications already do this by default, all keyboard shortcuts are collected and configured in one place. I do hope that applications will have some way to suggest default keybindings (which the compositor is free to ignore) so the user won't have to open their system settings and configure everything manually for every new application that he/she installs (it's also hard to write tutorials for applications if every user has different keybindings, and annoying for people that sometimes use other user accounts than their own). The paranoid user is still free to configure his/her compositor to ignore all default keybindings or maybe pop up a confirmation dialog before accepting them. <blockquote type="cite">The second point: which key(s)/mouse button(s) to bind? This is the compositor’s job to choose that (hey, based on the user settings of course). It can have a GUI, a key file, whatever. I think we should allow the same binding to have multiple actions (see the fourth point). </blockquote> And vice versa: one action can have multiple bindings (e.g. a mouse gesture and a keyboard shortcut). We shouldn't limit it to just keyboard and mouse, the compositor should be free to use any mechanism it wants, such as gestures, joystick buttons, maybe even voice commands. </div> <blockquote cite="mid:52B46F25.3090907@sardemff7.net" type="cite">I think this really specific use case *must not* be mixed with global bindings. We should probably have a global binding mechanism opened to every application and a specific trusted one for WhatPulse and friends. It could even be a system-wide LD_PRELOAD-like (*-like*, e.g. a specific hooking mechanism in wayland-server) thing that hooks in the wayland-server component and shipped with WhatPulse directly. </blockquote> I agree. The two are completely different use cases and different behaviour is expected. The crucial difference is that a global binding will 'eat' the mouse/keyboard event, i.e. the event will not go to the current application. If a user decides that the T key will be his push-to-talk key, then they probably don't want the application to see that keypress (this is actually a problem with Mumble right now). A global binding is also not a security risk (like a keylogger) because it would be obvious to the user that the keyboard isn't working (assuming untrusted programs can't generate artificial keypresses). In that sense it is no more dangerous than focus stealing. On the other hand a global mouse/keyboard listener is essentially an invisible keylogger and this functionality should only be given to trusted clients. I think in the long term Wayland will need both, just like X11 has both: the former is XGrabKey (which has a lot of problems and limitations that I hope Wayland will solve), and the latter is the XTest extension. The first one is probably more important though, so let's focus on that first. Maarten Baert </div> </body> </html>