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.
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:
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..
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
A suggestion
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