[Development] A new approach for Qt main()

Simon Hausmann Simon.Hausmann at qt.io
Fri Dec 9 11:17:27 CET 2016

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.


From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Friedemann Kleint <Friedemann.Kleint at qt.io>
Sent: Friday, December 9, 2016 11:00:00 AM
To: development at qt-project.org
Subject: Re: [Development] A new approach for Qt main()


 > Q_GUI_MAIN(appInit, appExit);

Magic macros for main should be avoided, IMO.

A typical application main() can look like

     QApplication a();

     Initialization code for other libraries

     parseArguments(), return if failed

     show some FileDialog prompting for argument if sth was missing

     try {
     } 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.



Friedemann Kleint
The Qt Company GmbH

Development mailing list
Development at qt-project.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20161209/51ba85e9/attachment.html>

More information about the Development mailing list