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

[Frank Reininghaus]

2014/1/4 David Faure:
> On Saturday 04 January 2014 14:51:52 Frank Reininghaus wrote:
>> Hi David,
>>
>> 2013/12/30 David Faure:
>> > On Friday 13 December 2013 11:28:01 Frank Reininghaus wrote:
>> [...]
>>
>> >> Still, I'm wondering if KFileItemActions should really delete all
>> >> actions it created, even if they belong to a widget that has been set
>> >> with setParentWidget(QWidget*). It works fine if KFileItemActions is
>> >> destroyed *before* the widget, because parent QObjects listen to the
>> >> 'destroyed' signal, but if the destruction order is different for some
>> >> reason, then we might get a crash because we try to delete dangling
>> >> pointers, right?
>> >
>> > Right.
>> >
>> > I think the parent for the actions should be the KFileItemActions instance
>> > instead. That would make all use cases happy, and follow the principle of
>> > least surprise, right?
>>
>> yes, that sounds reasonable!
>
> OK. Want to test that change, or should I just do it blindly in frameworks?

One could also add a unit test that does the "first delete the parent
widget, and then the KFileItemActions instance" thing and verify that
it crashes with current kio master and passes if KFileItemActions owns
the actions. I'll have a look.

>> Should we then remove the
>>
>> void setParentWidget(QWidget *widget)
>>
>> member in frameworks, or better make it a no-op and deprecate it in
>> order to not break source compatibility?
>
> None of these. The method still makes sense, it provides the parent widget for
> any dialogs shown by this code. As documented [unlike the parent ownership,
> which wasn't documented].

You're right, of course. Thanks!

Best regards,
Frank