info at michael-jansen.biz
Mon Mar 17 02:50:00 GMT 2008
Some ramblings over global shortcuts.
I have some problems with the current state of global shortcuts. So i tried to
write up what >I< think is correct behavior. Some kind of vision i would say.
The things that annoy me currently
1. I don't care for applications registering global shortcuts without telling
me and without giving me the oppurtunity to disable them. I start a
application i don't know, accidently press some button combination and
something happens. Don't like it.
No global shortcuts without my consent. Basta. A application is allowed to
advertise actions it thinks are appropriate for global shortcuts, and give
default values, but after starting the application the first time they
arent active. It's opt-in.
2. I don't care for kde shortcut dialogs dictating that having two
applications listening to the same global shortcut is a conflict and not
When i want to configure a conflicting shortcut let me do it. A warning
would be ok. Especially when shortcuts are opt in (1). I can imagine use
cases were pressing one shortcut should trigger two or three actions and i
would want that. And i don't think pointing to khotkeys is the right thing
to do in that case.
3. When running a application i do not care for kde telling me there exists a
conflict between global shortcuts when the other application isn't running.
Warn me when two applications listen to the same shortcuts at the
same time. Perhaps give me the option to suppress that warning for selected
4. I don't like having all shortcuts together in kglobalshortcutsrc. Call it
personal preference. I think the belong into the kxmlgui.rc file of the
How i think it could work
1. If a component ( see KComponentData ) registers a shortcut for the first
time. kdedglobalaccel registers the component as inactive. The component
goes on to registers it's global shortcuts but they won't be active. Code
wise i see no changes. Everything could happen behind the scene. ( Where do
not kxmlgui applications store their shortcuts? Not kxmlgui kparts are
2. During that registration the component tells kdedglobalaccel the location
of its kxmlgui*.rc file ( i think that's possible ). kdedglobalaccel would
need that if the user wants to configure global shortcuts and the
application is not running. With that information the keys kcm would be
able to inform you of conflicting shortcuts during configuration. But only
conflicting shortcuts for active components.
When the application is active the keys kcm would inform the application
via dbus of changes. No problem there.
I thinks it's a one component - one kxmlguiclient*.rc file association.
3. Sometimes later the user activates the global shortcuts for this component
using the global shortcuts configuration dialog (Some global checkbox). NOW
the dialog checks for conflicts with other active global shortcuts. It
doesn't matter if the other application is active or not. It's my choice to
ignore the warnings.
4. I start a application. It happens that it has a global shortcut conflicting
with that of another active application. Warn me. Give me the option to
disable global shortcuts for one of the application temporarily,
persistent or go to the global shortcut editor.
i18n -> How could the kcm know the localized name of the actions? Store it
into the kxmlgui*.rc file. Dirty but workable. A additional file?
Most client code could stay the same.
And now to something completly different:
I think there are most probably controversial changes to be made.
1. Currently it's possible to switch a action from one component to another.
That is done by putting it into a actioncollection belonging to a different
component. That is sometimes done unconsciously during the creation of
Action in kparts. new KAction -> action doesn't belong to a
actioncollection so it belongs to the main component. Then putting it into
the action collection belonging to the kpart ( different component ).
I don't think this should be allowed. And it proved very difficult for the
global shortcuts handling. Global shortcuts get informed that component
main wants to listen to a shortcuts. And then that information isn't worth
a cent anymore because the same action belongs suddenly to component
We should disallow that. Which means
a) KActionCollections component should only be allowed to change when the
collection is empty.
b) Moving a action between collections should only be allowed when both
belong to the same collection.
Those changes would break some existing code. And those changes wouldn't be
necessary when implementing the changes i proposed above. kdedglobalaccel
would only need to know which component wanted to listen to which shortcut.
And so it's not as bad as changing the component currently is.
I hope all of that makes at least a little bit sense and i do not have to many
Thanks if you read that far.
And be nice.
More information about the kde-core-devel