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, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
