KDE4 And Application Shortcut Conflicts

When working with shortcuts you sooner or later encounter the problem of having action shortcut conflicts. Action shortcuts conflict if they are active in the same context and are either identical or one is part of the other (ambiguous).

Conflicting shortcuts in a kde4 application trigger some very frustrating behaviour: None. Nothing happens. No action is triggered. QShortcutEvents has a property to check if an event is ambiguous. QAction::event() checks if it is set and then silently drops the event. No signal is emitted.

Current State

There are three sources for conflicting shortcuts in KDE applications: shortcuts, standard shortcuts (KStandardAction and KStandardShortcuts) and global shortcuts. Global shortcuts are out of scope for this post.

KKeySequenceWidget provides checks for all three possibilities. KShortcutsEditor can be configured to use those checks. Possible checks are:

  • Check against the other shortcuts in the same application. This is only possible if the developer registered all of his action with the editor. If a conflict is found the user is offered the possibility to steal the shortcut. If he declines the shortcut is not assigned. This will not work if the conflicting action is a QAction. In this case the user is told he can't have that shortcut. I don't know the reason for that behavior but won't change it.
  • Check against standard shortcuts. That makes only sense for global shortcuts. If the standard shortcuts is used by an application it is a conflict between local shortcuts. If it isn't used by the application it makes not sense to warn the user about it. If a conflict is found the user is warned about the conflict but is allowed to proceed.
  • Check against global shortcuts. If a conflict is found the user is asked if he wants to steal the shortcut. If he declines the shortcut is not assigned.

There is currently no automatic way in kde to check if two or more actions have the same shortcut assigned. KDE4 code only checks for shortcuts conflicts when the user assigns a new shortcut within the shortcut editor or with QKeySequenceWidget. But this check won't catch all conflicts anyway. To be clear: KDE does not check on application initialization for shortcut conflicts..

So how do we get conflicting shortcuts?:

  • The default shortcuts of a application are conflicting. This is especially a problem for applications using plugins. .
  • The user edits the applications configuration file per hand.
  • The user changes a standard shortcut with the standard shortcuts kcm. This change affects many applications but it is not possible to check all of them for conflicts. In fact none are checked.

An idea?

There is an idea i have for some time but never got around to test it. Because the next six weeks my time will be very scarce again i put the idea out here. Perhaps someone out there is willing to work on it. If you think it's not feasible tell me, so i won't loose time on it.

The idea is to override QObject::event in KAction. Instead of silently ignoring ambiguous shortcuts we could register them for later use on a singleton. If not yet done use QObject::invoke() to invoke a method on that singleton to display the conflicting shortcuts and give the user the possibility to inform him about the conflict and give hime the possibility to select which one to trigger. The theory is that Qt emits activatedAmbigous() for all shortcuts before returning to the event loop.

Feasible?

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

A suggestion

I want to thank you for working on shortcuts in KDE. Unfortunately, I can't help you with code, but I can give you a suggestion. Regarding that you don't have much free time maybe is best to leave shortcut conflicts as is (or as it was in 3.5) and focus on having as much 3.5 features as possible in 4.2 without introduction of new bugs. So, about that three points:

1. Default shortcuts are assigned by developers, so it is their responsibility to assign shortcuts that are not in conflict.
2. If they do that then they probably know what they are doing.
3. Yes, this is probably hard to implement. For now, you can just add a notice to the standard shortcuts kcm about this.


Regards!

Widget-defined shortcuts

Reading Bug #167422 I notice that kdeui::KCharSelect sets QShortcuts for several of its children (e.g. Ctrl+L for the search line).

I don't get what your idea does, so I won't comment on it, and just show this example here.

Post new comment

The content of this field is kept private and will not be shown publicly.
CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.