Comment on global shortcuts security
rickstockton at reno-computerhelp.com
Mon Oct 1 12:13:48 PDT 2012
On 09/30/2012 09:08 AM, Bill Spitzak wrote:
> << SNIP >>
I hope these comments are useful; if they're just a bunch of obvious
"baggage", I apologize.
> All the normal keystorkes that a client handles are a roundtrip, so I
> really can't see this being a problem. I certainly agree with
> Wayland's design that once a client decides to change it's display,
> that it be able to do that with no further roundtrips. But that is
> different than event handling.
>> Furthermore, it
>> allows clients override global shortcuts of the compositor, which
>> means that it would be impossible to have secure shortcuts, e.g.
>> "kill this client" or "switch sessions".
> There certainly would still be "secure shortcuts" like you describe.
> These are identifiable to the user as "you hold down lots of strange
> shift keys". For instance ctrl+alt+del. The reason "lots of strange
> shift keys" are needed is to avoid breaking applications by blocking a
> keystroke the application designer thought was available. My main
> concern is that we don't have to make *ALL* shortcuts "lots of strange
> shift keys".
> The type of shortcuts I think me and Daniel are worrying about is the
> volume buttons. I would like hitting the volume button to change the
> volume in the current app that has focus, and only change the global
> volume if that app does not have a local control.
You are suggesting a design with which I agree:
First-priority WM/Compositor shortcuts (e.g., switch from a frozen App
Window; halt the entire user's Session) are "owned" by Weston, in an
unconditional manner. Weston will act on these "lots of strange keys"
Events before the App even gets a chance to see them events (Keyboard
for usre; and maybe some user-specified Pointer Evts., if we do offer a
"registry" implementation which users can modify for themselves.)
Second-Priority Weston shortcuts are "lots of strange keys" (AKA
"keysequence" of length one, or more, events in the correct order) ...
which were offered to the Application and returned to Weston (or another
WM) as un-handled events. Or, they are directly generated within the
application via logic (or GUI events), leading to an App request that
the "shortcut" be used. This is the land of HIG, and IMO Weston/Wayland
needs to create and document such guidelines: Analogous to a new column
in the "shortcuts" which are understood by Qt, when a Qt Application
runs within KWin versus Gnome or OS-X Window managers. (Reference
For example, an Qt Application request to switch to "fullscreen" will
pass Ctrl+Meta+F on OS-X, F11 on KDE (which can also use Ctrl+Shift+F),
and Ctrl+F11 under Gnome. The program is compiled ONCE, and the
alternative implementations of the corresponding keysequence are
executed within the Qt library.
In the particular case which you're describing: This is not a
"First-priority" WM shortcut. We should pass the volume button "press"
evt. to the Application with keyboard, allowing it to process in a way
which it chooses. If it ignores the key, then the key event should be
RETURNED from the application (or even generated by the Application),
"back" into the WM/Compositor, where we may apply it globally.
>> Third, if the client
>> hangs, it would mean global shortcuts would stop working, and you
>> could not e.g. alt-tab away from a frozen window, which might be
>> even fullscreen.
> There would be a timeout, same as being suggested for the window drag
> controls, after which the shell acts as though the client ignored the
>> It would also mean, that every application would need additional
>> code to cooperate with the compositor. Missing that code would by
>> default stop all global shortcuts from working. Programmers would
>> have to spend effort to not break the *whole* desktop, instead of
>> just having their app working right with the desktop by no effort.
> This just requires toolkits to require a "I used the key" return value
> from keystroke handlers.
IIRC, The Qt/KDE design is the opposite: If they "USED" the key within
some level of code (class or interface), then they suck it in and
nothing comes back to Weston. If they want to ignore the key, then the
keystroke event gets "pushed up" through all of the Application classes,
eventually reaching the top-level window. And that Window passes it back
to the WM/Compositor.
> The amount of work for a programmer to support that is trivial (they
> are likely calling several functions that already return this
> information), and failure of the programmer to do this will result in
> obvious bad behavior of the application (such as breaking Tab
> navigation) even if there are no global shortcuts.
>> You might invent elaborate schemes to overcome the latter cons,
>> but even the roundtrip argument alone is a serious one, and there
>> would have to be a serious benefit in doing so. This would just
>> bring a lot more problems than it would solve.
> I'm worried that a "shortcut registry" will add enormous complexity
> and bugs and make it difficult for programmers to get the behavior
> they want.
That depends how complex/ sophisticated Weston intends to become. If
Weston will eventually have spinning cubes of multiple Desktops and/or
"workspaces", then we'll need to let users avoid "sequences" which
applications want to use. And we'll need to have pointer support- for a
number of buttons which is AT LEAST competitive with Compiz. If we want
to leave Weston as a more limited Compositor,
- - - - -
With those introductory comments we get to the "guts" of my reply:
Perhaps Weston/Wayland HIG should be defined with a clear distinction
between those "Global Shortcuts" will be taken and executed by
Wayland/Weston before an application can even see them, versus other
"Global Shortcuts" which will only execute a global Wayland/Weston
function when passed back, in a round trip, from an Application program
which chose to ignore it.
Do you intend to support EMACS-style "keysequences" of separate events,
or merely single-event combinations of modifiers with key(s)? The latter
brings up issues of A18n .... if you're typing with a single-pointed
tool in your mouth, it's REALLY HARD to hold "Ctrl" and "Alt" at the
same time you press "Del" ;)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wayland-devel