KAutoPointer: a new autoptr class for QPointer
frank.osterfeld at gmx.de
Mon Jul 13 15:45:06 BST 2009
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
> 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
Here the parent widget also takes ownership of the dialog, thus std::auto_ptr
and QSharedPointer approaches won't work.
More information about the kde-core-devel