KAction changes

[Andreas Hartmetz]

Well, it was planned (by Olivier Goffart and me) to add mouse gesture
and voice triggers to KAction. From a user's perspective they probably
don't *need* to be handled by KAction, of course. From a programmer's
perspective however, this seems to be the only way that makes sense. I
have not yet done anything to implement voice gestures (and I don't
know if I will be able to pull it off at all) but mouse gestures are
actually pretty easy to add to KAction, I tried that. You need a
KGestureMap (== event filter for KApplication with gesture recognizer)
for each application and some fields in KAction's private data.
If everybody stops using KAction, it might become difficult to add any
additional  triggers to random actions. For example, a user might want
to add a mouse gesture to an action that does not have a predefined
gesture.

Cheers,
Andreas

2006/12/4, Simon Hausmann <hausmann at kde.org>:
> Hi,
>
> KAction currently inherits from QAction and extends it by a few properties,
> along with plenty of compatibility API. KAction is also the type used in all
> of our public API and that is unfortunately a problem. It means that it is
> not possible to use for example QDockWidget's toggleViewAction or
> QUndoStack's created actions in KDE APIs, such as KActionCollection, because
> all those methods require a KAction. For no good reason we (that's Kévin and
> me) think.
>
> So as a result Kévin removed most of the KAction usage in our public API (in
> branches/work/kaction-cleanup-branch) and we ported most of the modules
> already (in the same branch). It turns out to require only very few changes
> in application code, and in most parts it actually cleans up the code by
> replacing for example deprecated plug() calls with the proper addAction()
> calls.
>
> So we could like to merge those changes back into trunk, hopefully soon
> (maybe
> tomorrow evening?). The changes don't mean that KAction goes away (at least
> not directly), it merely makes our public API more consistent with Qt and
> more compatible as well.
>
> Does anybody have any additional input, objections or thoughts on this?
>
>
> Simon
>
>