[PATCH] Unbreak global shortcuts configuration

Aurélien Gâteau aurelien.gateau at free.fr
Wed Jan 30 21:33:30 GMT 2008

Lubos Lunak wrote:

> On ne 27. ledna 2008, Aurélien Gâteau wrote:
>> I guess people will object against applying the patches until #0 is
>> fixed, but I would like to have feedback about the others nevertheless.
>  I have a question: After writing these patches, do you understand how
> KdedGlobalAccel is supposed to work or is this just patching things up?
> From looking at the patches I get the feeling it's the sooner :) , if
> that's the case, could you please share this knowledge with others and
> write it down somewhere in kdedglobalaccel.cpp? It'd be really stupid to
> repeat the KDE3 KGlobalAccel case when every change meant just adding more
> hacks on top of previous hacks.

I won't claim to have understood all of it, but I sure gained some insight
about the way it works. Here is the big picture:

KAction instances talk to KGlobalAccel singleton to make it aware of global
shortcuts changes via KGlobalAccel::updateGlobalShortcuts() and
KGlobalAccel::updateGlobalShortcutsAllowed() (i'm still not sure why there
are two methods).

These two methods do the following:
- Create an action "id" which is a QStringList of two items: the application
component and the action text (this is bound to cause trouble with i18n)

- Convert the KAction shortcuts to a QList<int>

- Pass all this via DBus to the KdedGlobalAccel instance, which lives in the
kded4 process.

The KdedGlobalAccel is responsible for actually handling the shortcuts,
loading and saving the shortcut keys to kglobalshortcutrc. It doesn't
really know the actions, it just know what KGlobalAccel gave to it.

On the other side of the fence, the keys kcm gets the global shortcut info
from the KdedGlobalAccel instance via DBus. It uses KShortcutsEditor to let
the user edit the shortcuts. Since KShortcutsEditor manipulates KAction
instances, the kcm creates "fake" actions.

This is all I gathered. I am not sure it should be put in one cpp file since
it's about several classes. Maybe I can put this in a README file inside


More information about the kde-core-devel mailing list