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> on
behalf of Friedemann Kleint <friedemann.kle...@qt.io>
Sent: Friday, December 9, 2016 11:00:00 AM
To: 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
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
