KAction and KShortcut in frameworks

[David Faure]

On Thursday 10 May 2012 23:21:25 Mark wrote:
> As for "reset to defaults", i don't think that should be stored in a
> KAction abject. That feature is only usable in the Shortcut Editor
> (assumption) so having this for every single KAction in all KDE
> applications is a bit strange.

Not really, the default is also ... the initial shortcut, i.e. the shortcut 
that is used until the user changes it. See below for more.

> Since the KAction has a name as well (back
> button, forward button ... just look at Shortcut Editor) it becomes fairly
> easy to simply store the default shortcuts in some config (KConfig stuff)
> file somewhere. So we don't need "Reset to defaults" in KAction.

On one hand I like the overall idea of moving this out of the action class,
but on the other hand, how would this look from a developer's point of view?

Currently, you write
  KAction *newAct = actionCollection()->addAction("quick-connect");
  newAct->setText(i18n("Quick Connect"))
  newAct->setShortcut(Qt::Key_F6);
  connect(newAct, SIGNAL(triggered()), this, SLOT(quickConnect()));

Which sets the default shortcut to F6, and the user can change that later.

If the defaults are in some config file, then the developer would have to 
remember to write down that file and install it, and then either
A) duplicate the info into the code, to set the initial default shortcut, or
B) call some code that reads the shortcuts from the config file and applies 
them.

The first solution has the additional disadvantage that things will work out of 
the box from the C++ code, so nobody will remember to write and ship and 
install correctly the config file.

I see a different solution, which would be less troublesome for developers:
no config file, but an API in a different class. Something like
 KShortcutManager::setDefaultShortcut(newAct, Qt::Key_F6);
[implementation: either singleton with a QHash, or better, dynamic property on 
the action, less book-keeping and no risk of deleted action in a hash]

krazy would basically flag any direct call to QAction::setShortcut as a "bad 
hardcoded shortcut, you should use KShortcutManager instead".

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