KAction and KShortcut in frameworks

[Mark]

On Fri, May 11, 2012 at 6:31 PM, David Faure <faure at kde.org> wrote:

> 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]
>

I like this idea! I was actually intending to use the Shortcut Editor but i
didn't look into specifics yet.

With dynamic property you're talking about
http://qt-project.org/doc/qt-4.8/qobject.html#setProperty right?
I haven't done anything yet in that area so that will be interesting.


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

What you're suggestion is that _all_ KAction obects go through
KShortcutManager. Might be good for an ideal world situation but i don't
really know if this is desirable. I just don't know for this part.

>
> --
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
>
>
I do want to get back on KInputShortcut and KInputSequence about them being
not KDE specific and should end up in Qt. I fully agree and there has been
discussion about that some time ago on the Qt mailing lists. I actually
started that discussion so i know what i'm talking about :) The idea back
then was that global shortcuts should use the platform plugin stuff and
should use some kind of global shortcut storage mechanism. The thing that's
called "Shortcut Editor" in KDE. Mac and Windows sadly don't have such
applications. So the Qt implementation would be quite... difficult. KDE
already has some more infrastructure with global shortcuts so there it's
"fairly easy" to get the suggested approach working.

Let me stress again, it should be in Qt! Qt is only missing a few vital
parts that make it quite difficult to implement:
- Support for global shortcuts
- Storage for global shortcuts

So i would like to just implement this (including KInputShortcut
and KInputSequence) on KDE first for frameworks since KDE has the
infrastructure for this.

Cheers,
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120511/7e410286/attachment.html>