KFileItemActions - why does it remember the actions it created, and deletes them?

David Faure faure at kde.org
Thu Dec 12 22:23:42 GMT 2013


On Thursday 12 December 2013 18:38:23 Frank Reininghaus wrote:
> 1. In the openItemContextMenu() member of DolphinContextMenu, which
> inherits KMenu, we create a KFileItemActions instance on the stack,
> and use it to add actions to "this". The actions thus become children
> of "this".

Let me quote from the KFileItemActions documentation:

    /**
     * Set the parent widget for any dialogs being shown.
     *
     * This should normally be your mainwindow, not a popup menu,
     * so that it still exists even after the popup is closed
     * (e.g. error message from KRun) and so that QAction::setStatusTip
     * can find a statusbar, too.
     */
    void setParentWidget(QWidget* widget);

*not a popup menu* :-)

The documentation is incomplete though - what it forgets to say (oops), is 
that this parent widget will also be the parent of the actions.

I can't remember why it works this way, but at least I think you have an easy 
solution: call setParentWidget(mainwindow).

To answer the question in the subject: because if you don't call 
setParentWidget then the actions would have a null parent and therefore they 
would never get deleted....


> In all reasonable use cases, these actions
> become the child of a menu, which can care of the deletion, right? 

This isn't how QAction works. You create a single "Copy" action, and then you 
plug it into a menu (-> you get a menuitem), into a toolbar (-> you get a 
toolbutton), into the mainwindow (-> the shortcut works), etc. This is how you 
can easily synchronize the state between these various representations of the 
action, by using the same action, added to multiple container widgets.
Therefore, when you create an action and add it to a menu, it does NOT become 
a child of the menu. It only does so if you explicitely create it with the 
menu as parent [if that's what you meant, I apologize for the unnecessary 
explanation].

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5





More information about the kfm-devel mailing list