[RFC] Handling lobal shortcuts conflicts

Andreas Hartmetz ahartmetz at gmail.com
Thu Apr 12 02:55:19 BST 2007


Hello list,

In KDE 3 there is a system in place to find and resolve global shortcuts 
conflicts. If you choose (in KKeyChooser) a shortcut that is already taken by 
another applications' global shortcut, you will be asked if you want 
to "steal" it from the other application or choose another one.
This system fails in many cases.

If you do black-box testing, it looks like there is a predefined list of 
standard global shorcuts (like Klipper's) that you are not allowed to steal.
Stealing mostly(?) has no effect, and the system doesn't notice when a global 
shortcut in another application was changed so that the old shorctut is now 
available.
During examination of the code, it seemed to me like all global shortcuts were 
saved in the config file "kdeglobals" and conflicts were resolved by looking 
there for other shortcuts.
The truth lies somewhere in between (?) and frankly, I have given up research 
because the system doesn't work anyway.

We need something that works for KDE 4.

My idea is to use KGlobalAccel as the gateway to a config group in kdeglobals 
where *all* global shortcuts have to be registered, like
<Application-Name>:<Shortcut-Name> = <Shortcut>.
When a shortcut was changed, KGlobal Accel would send a DBUS signal to all 
applications  to update their instances of KGlobalAccel, similar to the way 
KDE 3 does this now.
The users of KGlobalAccel wouldn't have to know anything about this.
KGlobalAccel would be the one and only class that contains the guts of global 
shortcuts, nice and tidy. The config group that KGlobalAccel uses would be 
made fixed. Its configurability has no real advantage and it's a bit 
confusing.

Do you see any problems with this approach?
Do you have better ideas?
(How to remove entries of uninstalled applications? Is it needed?)

Cheers,
Andreas




More information about the kde-core-devel mailing list