[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