The future of KAction

[Simon Hausmann]

(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 
plug()/unplug().

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.

Simon