Subtle KAction::setShortcut bug

[Andreas Hartmetz]

Am Montag, 22. Oktober 2007 14:28:15 schrieb Hamish Rodda:
> Hi,
>
> I've just discovered a bug related to the non-virtual overriding of
> QAction::setShortcut() by KAction::setShortcut().  In kate, because
> KActionCollection returns QAction* rather than KAction*, the code setting
> up the actions used a QAction* to configure the actions.  Thus, the QAction
> version of setShortcut() is called.
>
> The bug is that KAction doesn't have its default shortcut set, and thus it
> thinks that the shortcut is a custom shortcut.  So, clicking Defaults in
> the shortcut configuration default will clear it (bug), and it will get
> saved to the config as a custom shortcut (which is also a bug but a less
> harmful one).
>
> This can of course be fixed in the app with a whole bunch of casts. 
> However, I'm concerned that it will happen in many applications.
>
> We could listen for ActionChanged events and respond to them, but that
> would be quite an ugly hack.
>
> I'd be interested to find out why the return value of
> KActionCollection::addAction(KStandardAction::StandardAction, ...) was made
> a QAction* rather than a KAction* - is there any reason for this? (I could
> at least avoid heaps of casts).
>
AFAIK it was planned to move to mostly QAction in our API. That didn't work 
out that well, I think. So I'd say that moving from QAction to KAction 
wherever it solves a problem is fine.

> Perhaps an audit of setShortcut calls could be performed... *shudder*
>
> Any other ideas?
>
> Cheers,
> Hamish.