KAutoPointer: a new autoptr class for QPointer

[Frank Osterfeld]

On Friday 10 July 2009 12:36:07 Lubos Lunak wrote:

>  I would argue that the problem in http://www.kdedevelopers.org/node/3919
> is a problem on its own and as such the solution is DONOTDOTHAT. I believe
> that quitting an application with a modal dialog open should not quit, but
> instead should require the user to close the dialog first.

I agree that there might be better solutions than using KAutoPointer on modal 
dialogs everywhere (which is still a lot better than QPointer + delete).
But given that we have lots of code that just deletes widgets without any kind 
of "shutdown protocol", like calls to quit() or KPart shells like Konqueror do 
with embedded KParts/their views when they are not longer needed, the 
KAutoPointer approach seems the least intrusive fix for those crashes. 
I also don't see how QDialog::exec() usage could be fixed properly, and I don't 
see anyone starting major refactoring of all the QDialog usage inside KDE to 
avoid exec() (and modality alltogether).

>  It appears to be also technically wrong, since when exec() in
> ParentWidget::slotDoSomething() is called, the control flow should continue
> by returning from it. That part actually confuses me a bit, since I don't
> know what exactly happens behind the scenes, but I assume that quit()
> somehow destroys some data including the dialog and then returns control,
> and in that case this is just patching over a small problem and asking for
> a much bigger one. If quit() really does this, then it is a bug. First

It's not just quit, anything that deletes your widget causes the problem. 
Unless your application (and applications embedding your code if it's a lib or 
component) is designed to never do that, you will run into such issues.

> ParentWidget::slotDoSomething() should return control to the main loop and
> from there the exit and cleanup should really happen.

Can you elaborate how that would look like in code? I.e. how slotDoSomething() 
should handle the case that quit() was called or konqueror wants to delete the 
widget in between?

>  And I have also design issues with KAutoPointer. It appears to me as a
> random mix of do-everything-pointer. QPointer is a class that watches a
> QObject that belongs to something else and that's it, simple. std::auto_ptr
> or
> boost:scoped_ptr are classes that take ownership of the pointer and take
> care of deleting the object when the time comes. Now, KAutoPointer is what,
> a class that takes ownership of the object, but not really, since it's fine
> if somebody else wipes it out too? That's not design, that's a hack.

It's a "make sure the dialog is deleted, one way or another" pointer that 
combines the ownership model of QObject with std::auto_ptr-like behavior. It 
might be too much of a special case to justify another pointer class, but then 
we need another solution.

>  That said, I would strongly support it if KDE finally embraced the 90's
> and started using some kind of a scoped pointer. By which is mean something
> that basically just takes ownership of the object and does delete in the
> dtor.

Here the parent widget also takes ownership of the dialog, thus std::auto_ptr 
and QSharedPointer approaches won't work.

Frank