If we want to drop KHotkeys T2050 we should make working with KGlobalAccel as comfortable as possible.
Currently there is a
- Mix of functions that require a QStringList or a QAction parameter
- Some methods are static and others require the singleton object
- There are still some methods around that are deprectated since KDE 4 times
Additionally the API is cumbersome to use because you need the action setShortcut was called on or one that looks like it. If the shortcuts are defined in a desktop file that means
manually constructing QActions and duplicating the strings in the desktop file. Interacting with KGlobalAccel though these QAction parameters is not transparent. It just works if you use KActionCollection (if your program name matches your componentName which I don't know if this is the case when using desktop files). But when you have to manually construct actions because you want to query information about the shortcuts defined in you desktop file there is no documentation that the objectName and componentName and componentDisplayName properties need to be set to their specific values
In the future if we want to embrace the use of desktop files also for shortcuts there should be an easy to use API for that. I have no idea how such an API could look like (actionsFromDesktopFile() or automagically shortcutsForThisApplication()?) so ideas are welcome.
Does anyone know of any user of Shortcut Contexts? Or is that feature just not needed?
There is also a fast path in some functions that assumes that every shortcut had a setShortcut call before and doesn't query the runtime again. This obviously falls flat if the shortcuts are defined outside of the program. This can of course be worked around locally to use the global functions (for example in KShortcutsEditor in KXmlGui) but maybe something to think about in a post programs call setShortcut at startup world.
@fvogt: Decouple it from QKeySequence