<div class="gmail_quote">On Fri, May 11, 2012 at 6:31 PM, David Faure <span dir="ltr"><<a href="mailto:faure@kde.org" target="_blank">faure@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On Thursday 10 May 2012 23:21:25 Mark wrote:<br>
> As for "reset to defaults", i don't think that should be stored in a<br>
> KAction abject. That feature is only usable in the Shortcut Editor<br>
> (assumption) so having this for every single KAction in all KDE<br>
> applications is a bit strange.<br>
<br>
</div>Not really, the default is also ... the initial shortcut, i.e. the shortcut<br>
that is used until the user changes it. See below for more.<br>
<div class="im"><br>
> Since the KAction has a name as well (back<br>
> button, forward button ... just look at Shortcut Editor) it becomes fairly<br>
> easy to simply store the default shortcuts in some config (KConfig stuff)<br>
> file somewhere. So we don't need "Reset to defaults" in KAction.<br>
<br>
</div>On one hand I like the overall idea of moving this out of the action class,<br>
but on the other hand, how would this look from a developer's point of view?<br>
<br>
Currently, you write<br>
  KAction *newAct = actionCollection()->addAction("quick-connect");<br>
  newAct->setText(i18n("Quick Connect"))<br>
  newAct->setShortcut(Qt::Key_F6);<br>
  connect(newAct, SIGNAL(triggered()), this, SLOT(quickConnect()));<br>
<br>
Which sets the default shortcut to F6, and the user can change that later.<br>
<br>
If the defaults are in some config file, then the developer would have to<br>
remember to write down that file and install it, and then either<br>
A) duplicate the info into the code, to set the initial default shortcut, or<br>
B) call some code that reads the shortcuts from the config file and applies<br>
them.<br>
<br>
The first solution has the additional disadvantage that things will work out of<br>
the box from the C++ code, so nobody will remember to write and ship and<br>
install correctly the config file.<br>
<br>
I see a different solution, which would be less troublesome for developers:<br>
no config file, but an API in a different class. Something like<br>
 KShortcutManager::setDefaultShortcut(newAct, Qt::Key_F6);<br>
[implementation: either singleton with a QHash, or better, dynamic property on<br>
the action, less book-keeping and no risk of deleted action in a hash]<br></blockquote><div><br></div><div>I like this idea! I was actually intending to use the Shortcut Editor but i didn't look into specifics yet.</div>

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

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
krazy would basically flag any direct call to QAction::setShortcut as a "bad<br>
hardcoded shortcut, you should use KShortcutManager instead".<br></blockquote><div><br></div><div>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.</div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
--<br>
David Faure, <a href="mailto:faure@kde.org">faure@kde.org</a>, <a href="http://www.davidfaure.fr" target="_blank">http://www.davidfaure.fr</a><br>
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5<br>
<br>
</font></span></blockquote></div><br>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.<div>

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

<div><br></div><div>So i would like to just implement this (including KInputShortcut and KInputSequence) on KDE first for frameworks since KDE has the infrastructure for this.</div><div><br></div><div>Cheers,</div><div>Mark</div>