Global shortkeys and keyboard focus

[Fabrice Rey]

The shortkeys I'm referring to are typically <modifier1><modifier2>...<key>
so <super>z, <ctrl><shift>f1, etc.
Currently, in the application each applet registers a shortkey with a
description, its icon, and a callback. So all shortkeys are configurable
from a single place in the UI.
The user can double-click on a shortkey to enter a new one, so any shortkey
that is already used will not work (because it will just trigger the action
and be intercepted); however ctrl<c> would still reach the UI and be
accepted, at least currently it is.
Then, when a shortkey is pressed, the application receives an X event, find
the associated callback and calls it.

So it's similar to the idea of having an UI in the DE's configuration that
lists all available shortkeys registered by all applications.
It's also similar to the idea of having the compositor acting as a
man-in-the-middle (dispatching signals to applications that registered
shortkeys).

It remains to see how secure it could be.
If you let an application registers only empty shortkeys (so it only adds a
new description+icon in the list of triggerable actions but by default it's
not linked to any shortkey) then there is no risk a malicious application
could listen for any keyboard events; because the user would have to
manually define a shortkey first.
It also means that by default an application will not have any shortkey,
the user will have to go to the UI and define the shortkeys after
installing an application that have triggerable actions.
That cold be seen as a flaw, but you could argue that the newly installed
application has no way to know if its default shortkeys will be available
or will be effectively accepted by the compositor, so maybe it's not so bad
to force the user to define its shortkeys.

Another way is to let the application register an actual shortkey, and then
on first trigger, ask the user if he's ok.

Or let the packagers authorize an application to register any shortkey (by
installing some policyKit-like files); this could also be for several other
priviledged actions.

In any ways, the compositor would always be the one that accepts/refuses a
shortkey and calls the application.


2014-07-04 18:57 GMT+02:00 Thiago Macieira <thiago at kde.org>:

> On Friday 04 July 2014 14:04:03 Dodier-Lazaro, Steve wrote:
> > The problem is: what are the allowed global shortcuts leaking about
> users?
> >
> > If it's any key that can be listened to, then we've just gotten
> ourselves an
> > API for implementing keyloggers.
>
> Just because the API and standard allow any key to be requested does not
> mean
> that the compositor will honour that request. It can have a rule that
> limits
> which shortcut combinations will be allowed. And obviously it should refuse
> any that conflict with its own shortcuts. But we should have a
> recommendation
> to applications as to what modifiers are most likely to be accepted, which
> in
> turn means applications should avoid using those key combinations as non-
> global shortcuts in their UXs.
>
> The compositor can also ask the user if it's unsure: "confirm you want this
> application to use this global shortcut".
>
> The compositor should remember which applications requested what, so as to
> avoid conflicts or at least inform the user when that happens.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140705/e886d719/attachment.html>