KDE4 default shortcut theme

Jakob Petsovits jpetso at gmx.at
Thu Mar 29 16:22:46 BST 2007


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 :-}

Regards,
  Jakob




More information about the kde-core-devel mailing list