KAction and KShortcut in frameworks

[David Faure]

On Friday 11 May 2012 21:07:58 Mark wrote:
> The only reservation i have is the case where some developer comes by and
> makes a KDE application with actions that aren't defined yet in Shortcut
> Manager. 

I'm not sure what you mean by 'not defined yet'...

KShortcutManager will not have any knowledge of anything, it will just be a 
two-liner method that sets a property on the action.
Maybe "Manager" is a confusing term, in fact, but I don't have a better idea 
right now.

> Then that developer might just wnat to use setShortcut which is
> fine right?

Not if the application uses the shortcut editor dialog, which all KDE 
applications should use anyway (and most get it automatically via xmlgui).

To restate:
If an application doesn't use the "KDE way of setting default shortcuts" 
(current proposal KShortcutManager::setDefaultShortcut(act, key[s]))
then these shortcuts won't be configurable, which is a bug if you use the 
shortcut editor dialog.

> How about the current KShortcut and KAction stuff along with deprecation. 
> What should be deprecated, Where should it be deprecated (in 4.9 is my
> preference)

Major API changes should be done in 5.0, not in 4.x, especially when the full 
replacement isn't available yet in 4.x!

> and how about my current patch in reviewboard? Is that one
> becoming obsolete with this idea? (seems like it)

Yes, although we could also say that if it goes one step further, changing the 
dynamic properties into a single list of shortcuts, and adapting the shortcut 
editor to that, then *that* work will be useful for the future.
It's just the API changes themselves, which are not so useful if the plan is 
to get this into Qt anyway.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5