2015-04-14 16:36 GMT+02:00 Thiago Macieira <thiago.macie...@intel.com>: > > 2) fix it by not passing through notify() outside the main thread. That's the > solution I implemented in I27eaacb532114dd188c4ffff13d4ad2a4bb443e6. >
People rely on QCoreApplication::notify to provide a try/catch when working with Qt and exceptions. That allows dealing with them in a single place, rather than in every single function called by a Qt event. If it stops working in threads, some applications will definitely see the difference. They won't necessarily break, as I seem to remember Qt has a generic try/catch around notify, but they will loose any information from the exception. Is it that common to destroy the application object will threads are still delivering events ? It feels weird to me... It would be a shame to fix a uncommon case by breaking a common one. Just thinking out loud, but assuming it isn't that common, would it make sense to provide a setting to choose between the two behaviors ? Or a Qt function/slot one need to explicitly call from the most derived application destructor when needing to continue processing events ? Or provide a different way of creating/destroying the application object when this behavior is required ? Julien Cugnière _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development