The future of KAction

Simon Hausmann hausmann at
Fri Nov 11 10:55:57 GMT 2005

(great Hamish that you're looking into this, btw!)

On Friday 11 November 2005 07:38, Hamish Rodda wrote:
> * unplugAll() and isPlugged().  QAction currently does not expose which
> widgets the action is plugged into.  The only way around this that I can
> see would be using a QApplication event filter which watches for add and
> remove action events, and tracks them in KAction.  Deleting the QAction
> automatically removes it from all of the widgets it is plugged into, so the
> same effect could be achieved by deleting the action, and recreating it if
> needed.  Alternatively, the trolls may be persuaded to expose this list if
> we ask very nicely (I think it's reasonable enough).

I wonder how useful these functions really are nowadays, btw.

unplugAll() was IIRC introduced to get around the fact that it was 
hard/impossible to properly implement this in the destructor, as it requires 
every subclass destructor to do something like that, due to the virtual 

But with the new QAction pattern inheritance does not make sense anymore 
because QAction is just a (more or less) dummy container, the API is unified 
in the sense that the menus/toolbars know about actions themselves.

So I think the actual replacement for unplugAll() with QAction is just to 
delete the action and re-create it if necessary.

Can anyone think of a use-case for isPlugged()?

The isPlugged(QWidget *container) overload is obviously not necessary, given 
that QWidget nowadays keeps track of attached actions.


More information about the kde-core-devel mailing list