On Saturday, 9 November 2013 23:45:20 CEST, Albert Astals Cid wrote:
> But I don't think that's a problem anymore. I tried to crash it=20
> by doing what=20
> the blog says and it doesn't crash, and after having a look at the=20
> KApplication::quit code that calls QCoreApplication::quit()=20
> code I think that=20
> this has been fixed in Qt since QCoreApplication::quit doesn't "destroy"=20=

> anything, just makes the event loops quit, so stuff is deleted properly.

It's still a problem because it starts a second event loop. The second=20
event loop will process any events and there could easily be some=20
application-level code which deletes some objects, perhaps the parent=20
QWidget (of a parent of...) of the dialog.

I've wasted my fair share of time on this in Trojita where we disconnect=20
from the IMAP server upon seeing a network error. This, naturally, leads to=20=

freeing memory of some auxiliary objects, and that was a problem when these=20=

objects were stuck in e.g. a GUI prompt for password.

The QPointer<QDialog> indeed looks like a kludge. The right way (tm) is,=20
AFAIK, to use asynchronous state everywhere, i.e. have dialogs connected to=20=

slots of the object which triggered them. That's also the only way to do=20
these prompts in QML, by the way. Yup, it's more code, but it's needed,=20
IMHO.

Cheers,
Jan

--=20
Trojit=C3=A1, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/