Special macros for straightforward applications on exotic systems? Sure. Forcing an unnecessary change on existing and future applications on platforms that are doing just fine (i.e. the majority)? No.
Building on Friedemann's example the list of potentially problematic cases could go on forever. For example, what if you need to set certain application attributes, default surface formats, etc. before the Q(Gui)Application construction. Or the special cases where app object creation should be carefully placed. In the end those macros would need to get a lot more complicated than they look at first. Based on all the negative experience with testlib's similar and the qtdeclarative examples' main-wrapping macros, I'd rather prefer we think twice before introducing any such macros. Also, if migration for the typical applications is seen that easy, it should be no problem for developers targeting exotic systems to provide a new-style entry point in their apps. Best regards, Laszlo From: Development [mailto:development-bounces+laszlo.agocs=qt...@qt-project.org] On Behalf Of Simon Hausmann Sent: Friday, December 9, 2016 11:17 AM To: Friedemann Kleint <friedemann.kle...@qt.io>; development@qt-project.org Subject: Re: [Development] A new approach for Qt main() Yes, and we will forever (?) support that kind of main function and application entry point. I don't think that we can break that. I'm all interested in supporting a second supported way of describing an entry point that more closely matches today's semantics of graphics applications on the underlying operating/windowing systems. Oddly, I do like the way that we're doing this on Windows and have been doing it forever, by shoehorning main() into WinMain() through a static library. I'm not suggesting to replace QtMain, but I wonder if we could offer a cross-platform QtMain (with a different name that doesn't clash with the existing one) that requires the programmer to supply a _two_ (or more?) functions instead of one function. No macros involved then. Simon ________________________________ From: Development <development-bounces+simon.hausmann=qt...@qt-project.org<mailto:development-bounces+simon.hausmann=qt...@qt-project.org>> on behalf of Friedemann Kleint <friedemann.kle...@qt.io<mailto:friedemann.kle...@qt.io>> Sent: Friday, December 9, 2016 11:00:00 AM To: development@qt-project.org<mailto:development@qt-project.org> Subject: Re: [Development] A new approach for Qt main() Hi, > Q_GUI_MAIN(appInit, appExit); Magic macros for main should be avoided, IMO. A typical application main() can look like main() { QApplication a(); Initialization code for other libraries parseArguments(), return if failed show some FileDialog prompting for argument if sth was missing try { app.exec() } catch (exception) { } De-Initialize something } There is no way to shoehorn this into some macro; this can already be observed when trying to adding some initialization to a test. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH _______________________________________________ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
