The future of KAction
hausmann at kde.org
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