Global Shortcuts

[Michael Jansen]

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
   acceptable. 
   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
   shortcuts.

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
   application.

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
   impossible? )

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.
   Right?

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.

Problems

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
   kpart_a.

   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
misunderstanding :-)

Mike

Thanks if you read that far.

And be nice.