Apologies, I should've expanded a little more on what I said. For example if we expose a QObject class to Qt instead of a function, then we could dispatch a static meta-call to a static initialization function that is called before the constructor, if present. Introspection makes that quite easy I think.
Simon ________________________________ From: Simon Hausmann Sent: Tuesday, December 13, 2016 11:24:48 AM To: Laszlo Agocs; Mathias Hasselmann; [email protected] Subject: Re: [Development] A new approach for Qt main() Hi, I don't think it does handle those cases. But we're not talking about eliminating main(), we're talking about a second supported "launch" method. That said, it's still possible to run code before the constructor, although it's not pretty. Simon ________________________________ From: Laszlo Agocs Sent: Tuesday, December 13, 2016 10:42:05 AM To: Simon Hausmann; Mathias Hasselmann; [email protected] Subject: RE: [Development] A new approach for Qt main() Hi, How does this handle the cases that need code before the QGuiApplication construction? AFAICS it does not. Laszlo From: Development [mailto:[email protected]] On Behalf Of Simon Hausmann Sent: Tuesday, December 13, 2016 10:37 AM To: Mathias Hasselmann <[email protected]>; [email protected] Subject: Re: [Development] A new approach for Qt main() Hi, The joke of the bikeshedding aside I for one do like the idea of exporting a QObject sub-class instead of a function. That makes it easier to extend in the future with more entry-points as slots for example. Simon ________________________________ From: Development <[email protected]<mailto:[email protected]>> on behalf of Mathias Hasselmann <[email protected]<mailto:[email protected]>> Sent: Monday, December 12, 2016 7:53:50 PM To: [email protected]<mailto:[email protected]> Subject: Re: [Development] A new approach for Qt main() Hi, Seems this turned into a nice bike shed discussion quickly, so let me use the chance to present my preferred Qt main(). I am totally convinced that this one should rule the Qt world: class BlueBikeShedApplication : public QApplication { Q_OBJECT public: using QApplication::QApplication; int run() { if (!parseCommandLine()) return EXIT_FAILURE; if (!initializeColorBucket()) return EXIT_FAILURE; setupBrush(); return exec(); } }; int main(int argc, char *argv[]) { return BlueBikeShedApplication{argc, argv}.run(); } The big advantage I see in this approach is, that you work within a proper QObject context with fully setup QApplication early. Also this main() is sufficiently generic to be hidden in a platform specific macro, or static library. Thank you for reading, Mathias _______________________________________________ Development mailing list [email protected]<mailto:[email protected]> http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
