API changes to global shortcuts - let's get it over with...

[Andreas Hartmetz]

Hello list,

I would like to announce some changes to the way global keyboard shortcuts 
will be handled, likely due next monday. I tried tried to make "interesting" 
corner cases and conflicts impossible to create. Not having much application 
experience myself, I had a real life chat with Martin and Max(?) of Amarok. 
Here is a short description of what we came up with:

-When KAction::setGlobalShortcut() or ::setGlobalShortcutAllowed() is called 
for the first time ever on a KAction identified by a 
mainComponentName/actionName pair, the then active shortcut is stored in a 
KDED module.
-Whenever the action's "global shortcut allowed" flag is set in subsequent 
runs of the application, the stored value is loaded and, for 
setGlobalShortcut() (which sets this flag), the shortcut passed will be just 
ignored. If you *really* want to *change* the shortcut to something different 
programmatically you can indicate this by setting a flag noAutoloading. Note 
that this is something your users are not likely to want except if they asked 
for it.
-Conflicts will be avoided by just zeroing out any offending new shortcuts. 
The result will be saved as always.
-All global shortcut settings will automatically be made persistent by storing 
them in a config file.
-As mentioned in earlier mails, no multi-key global shortcuts like Ctrl+A,B. 
Apparently there is no way to implement these in non-hacky ways on at least 
(X11, Mac).

This seems to be the best compromise to solve this boring problem...

Incompatible changes are:
-removal of KGlobalAccel::readSettings() and ::writeSettings()
-semantic changes to KAction::setGlobalShortcut[Allowed]()
and behind the scenes, most things will be handled in a DBus-enabled KDED 
module.

Cheers,
Andreas

-- 
Narrator: "Boys from the city, not yet caught in the whirlwind of progress, 
feed soda pop to the thirsty pigs."