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 by doing what the blog says and it doesn't crash, and after having a look at the KApplication::quit code that calls QCoreApplication::quit() code I think that this has been fixed in Qt since QCoreApplication::quit doesn't "destroy" 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 event loop will process any events and there could easily be some application-level code which deletes some objects, perhaps the parent QWidget (of a parent of...) of the dialog.
I've wasted my fair share of time on this in Trojita where we disconnect from the IMAP server upon seeing a network error. This, naturally, leads to freeing memory of some auxiliary objects, and that was a problem when these objects were stuck in e.g. a GUI prompt for password.
The QPointer<QDialog> indeed looks like a kludge. The right way (tm) is, AFAIK, to use asynchronous state everywhere, i.e. have dialogs connected to slots of the object which triggered them. That's also the only way to do these prompts in QML, by the way. Yup, it's more code, but it's needed, IMHO.
Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
