Global shortkeys and keyboard focus

Pekka Paalanen ppaalanen at
Wed Jul 9 00:30:08 PDT 2014

On Tue, 8 Jul 2014 22:26:07 +0000
"Dodier-Lazaro, Steve" <s.dodier-lazaro.12 at> wrote:

> A couple of notes on the previous emails,
> Fabrice, so long as your app ensures that no third-party code can programmatically grab a shortcut without user agreement, it would make sense to let it have a privilege.
> Quite obviously a compo should have the last word and be able to refuse a request to grab a certain shortcut. If this happens, compo developers please do provide the requesting app a displayable/translatable explanation that your end-users would understand ;)
> I don't quite like the idea of a permission prompt from the compo for setting up keyboard shortcuts. In the vast majority of cases the user is already using a specific GUI for that and possibly setting up more than one shortcut (e.g. shortcuts to newly installed media app), so it'd be awkward for them to receive a permission prompt. I think privileges work much better here (or User-Driven Access Control with a button that when clicked displays a compositor-owned dialog inviting the user to select a global shortcut).

A wild thought in passing, which likely borrows from things
I've heard from others before...

What if applications would install config file snippets, a la
configdir design, which specify a semantic action by identifier
string, and the default suggested hotkey, gesture, or whatever. Or
maybe they would be in the app's .desktop file, whatever

The compositor would watch this directory, and when files there
change, it would read them and notice that e.g. now there is a new
hotkey action available. However, all that would do is light up a
marker somewhere in the desktop UI saying "you have new hotkey
actions available, click here to set up all your hotkeys".

So the new hotkey would *not* work simply by the app's actions or
by installing the app.

The user can go into the hotkey config dialog in his DE UI, there
see as highlighted the new things, and have the option to accept the
default key binding, choose another key, or just leave the action
unbound. The idea being that they are all under the DE (compositor)
control, that is under the user's control, and all in one place.

When the app is actually started, it will register for the semantic
action by its identifier string, and then it may or may not get it

No privileges needed so far as I can see. Also nothing above says
it must be Wayland protocol. It could as well be dbus. And it could
as well apply to X11-based DEs!

Or maybe existing DEs already have a hotkey registration system,
and we have to do nothing more on Wayland standardization

So it might not even be a Wayland thing at all.

If a hotkey action needs to do something that is most of the time
not allowed, like raise a window to the top (using a hypothetical
protocol I'm not sure exists yet), I suppose the simplest thing
would be for the hotkey action event to carry a "serial" like input
events do, so the app can use that as a ticket to allow the
"raise the window" request to be accepted. This would need
integration in the Wayland protocol.


More information about the wayland-devel mailing list