Fixing the Shortcut Mess

[Andreas Pakulat]

Hi,

this is my last try to get some attention to this idea on fixing the
mess with shortcuts in KDE. The idea was originally brought up by Jakob
Petsovis in the shortcuts-thread in march and I think it was largely
overlooked as the thread wandered off to discussing which shortcuts
everybody wants to have for what. I sent this to the usability people
with the result that shortcuts are going to put into a table on the web.
Which doesn't really help as developers that want to assign shortcuts in
some application (or plugin for an app) still need to look up and find
some shortcut that is not taken somewhere else.

The problem is especially with shortcuts that work outside of the
application that responds to it, like the shortcuts for
window-management for example or things like showing/hiding amaroks
window. To find out that Win+P is taken by amarok I have to install it
and search through its shortcut dialog, just to get to know why several
users of my application can't use Feature X which uses Win+P as default
shortcut.

Now Jakobs proposal is:
,----
| On Thursday, 29. March 2007, Ellen Reitmayr wrote:
| > Olaf and me went through the KDE system shortcuts and suggest a few changes
| > for the KDE4 default shortcuts. For one, we would like to add some
| > alternative keyboard combination for a higher consistency with other
| > systems, for the other we'd like to introduce several new shortcuts which
| > are required for full keyboard access (accessibility).
| 
| Ok, here comes the radical one.
| I say let's stop this discussion right now, at least in this form.
| Your proposals are very good ones, but like everywhere I observed in the past,
| the approach to search for new shortcuts goes like this:
| - Look what other systems do
| - Look which shortcuts are not yet assigned
| - Fill in shortcuts where possible
| 
| This approach is lacking a high-level structure - you can't begin to be
| consistent with other desktops if KDE + apps are not consistent with
| themselves.
| 
| I think it's necessary to define a scheme that tells us which range of
| shortcuts is "reserved" for which specific purpose. Namespacing, if you will.
| Something like:
| 
| - Ctrl-Alt-* is for desktop management/switching & panel stuff
| - Alt-* is for internal window management (menu access, closing/minimizing,
| pane switching, prev/next tab for the main document in mdi/tabbed windows)
| - Alt-Shift-* for access(ibility) keys
| - Ctrl-*, Shift-*, and Ctrl-Shift-* only for application-internal stuff
| - Win-* is not pre-assigned, subject to the user's preferences
| - F1 is help, F2 is rename, F3 is search next, all other F-Keys (except when
| used with modifiers other than application-internal ones) are subject to the
| application itself
| 
| Subject to be improved or modified, of course.
| If there is no such thing, we'll continue to have clashes between
| different "layers", and we'll continue to have inconsistent shortcut themes
| that no one can remember or even guess by themselves.
| 
| And if we have _that_, then we can start thinking about which specific
| shortcuts make sense in which context. Then we can specify a few
| application-internal shortcuts like Ctrl-F, Ctrl-O and the likes in the HIG,
| as part of the greater scheme. We can even have a few exceptions (but only in
| the global schemes, so that the applications are not affected) for stuff like
| Alt-Tab which is essential, standard, and doesn't clash with other shortcuts.
| 
| What doesn't fit in, after having specified all of this, is dropped.
| Amarok defining Alt-Ctrl-P as global shortcut for Pause? Drop that.
| Alt-Up, Alt-Left and Alt-Right as "Application Shortcuts"? Drop that.
| Ctrl-Escape for bringing up KSysguard? Drop that.
| 
| We need to have consistent shortcut schemes if we want anyone to remember
| them. And there must be no exceptions for anything except the most standard,
| most common shortcuts. Applications must not fuddle around with Alt-*.
| Just finding free shortcuts doesn't cut it, we need a vision.
| 
| That's that. You're now free to disseminate my lack of anticipating
| the bad bad consequences of being that strict :-}
`----

Having such a clear separation helps especially applications that need
many shortcuts, for example Quanta or KDevelop. But of course all other
apps benefit too.

So what I'm asking is: Can this be done for KDE4? Or should I stop
dreaming about no headaches when deciding for application shortcuts?

Andreas

-- 
You dialed 5483.