[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KAutoPointer: a new autoptr class for QPointer
From:       David Faure <faure () kde ! org>
Date:       2009-08-19 16:05:03
Message-ID: 200908191805.04038.faure () kde ! org
[Download RAW message or body]

On Thursday 23 July 2009, Frank Osterfeld wrote:
> On Thursday 23 July 2009 15:37:42 Lubos Lunak wrote:
> > > It's not just quit, anything that deletes your widget causes the
> > > problem.
> >
> >  It does not cause the problem, it is the problem. If they are my
> > widgets, I delete them, not some random anything.
>
> Well, or your parent widget because it itself is deleted. Otherwise the
> code that wants to quit the application or replace e.g. the KPart in
> Konqueror has to make sure that slotDoSomething() and everything else
> giving the control to the event loop is left before the widget is deleted.
> I don't see a good pattern that does that and can be applied easily to the
> existing codebase.

We solved the issue of "konqueror (via a redirection timer) killing the 
khtmlpart while it's showing a modal dialog" via a different hack, cf
KHTMLView::closeChildDialogs() in kdelibs/khtml/khtmlview.cpp.

> > > 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.
> >
> >   Arguing that at least something random should delete the stuff is like
> > thinking that garbage collection magically fixes all resource problems.
> > The solution is to fix the bug or at least show that it can't be fixed
> > and a workaround is needed. Not even the latter has happened, you just
> > said "hey, something deleted my widget behind my back, I propose this
> > class as a workaround".
>
> I just want to get rid of those crashes, in a fault-proof way. I still
> don't see a pattern that a) can be applied to existing code with realistic
> effort b) is easy enough to grasp c) doesn't require major Qt or kdelibs
> refactoring. 

Still, it's worth investigating why quit() can't be made to quit nested event 
loops first, then the outer event loops. No major refactoring, "just" a Qt 
bugfix.

I think changing the way we write modal dialogs is awfully ugly, especially
for a "rare" bug :(        (yeah it's rare, we lived with it for 10 years).

-- 
David Faure, faure@kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
[prev in list] [next in list] [prev in thread] [next in thread]