[Development] A new approach for Qt main()

[Andre Poenitz]

Whatever the problem is, I think we should try hard to have a solution 
that 1. does not use macros and 2. that does not optically change the 
int main(int argc, char *argv[]) { QApplication app(argc, argv)... } stanza.

Macros look and feel ugly and outdated in contemporary C++, are harder 
to debug, etc etc. Changing away from a normal main will make look Qt
code alien, not to mention the necessary adaptation in documentation
and each and every "getting started with Qt" tutorial out there. This would
be a high price to pay.

I have to admit that I don't really understand the scope of the problem yet. 
If this is about having customization points in the QApplication object's life 
cycle, or supporting multiple entry points or similar one could have e.g. 
a number of QApplication::setFooCustomization(std::function<...>)
static functions that can be used to register callbacks by the platform
specific Qt and/or user code. Also, the actual "application object" 
lifecycle does not have to be match the user's QApplication object
in main(). The real thing can be created whenever it make sense, and
what the user sees will only forward calls, or hold back calls, or possible 
finalize initialization or whatever using the registered callbacks.

For me it would be helpful to have a list of problems that need to be 
solved before discussing one specific potential solution.

Andre'


________________________________________
From: Development <development-bounces+andre.poenitz=qt.io at qt-project.org> on behalf of Lars Knoll <lars.knoll at qt.io>
Sent: Friday, December 9, 2016 11:44 AM
To: Simon Hausmann; Friedemann Kleint; development at qt-project.org
Subject: Re: [Development] A new approach for Qt main()

Well, the problem is that the main() entry point is causing huge amounts of issues on at least Android and iOS. We’d help those platforms a lot if we didn’t support this kind of entry point (on those platforms) anymore. But I agree that we can’t break this in Qt 5, but we can prepare for Qt6.

I’d propose to define a new entry point that works better on these platforms and offering that as the recommended way for new apps. The best solution is probably a static library that provides callbacks that can be used to initialize things.

When we then come to Qt6, we could deprecate using main() as the entry point, and remove support for it at least on the platforms where this is problematic.

Cheers,
Lars

From: Development <development-bounces+lars.knoll=qt.io at qt-project.org> on behalf of Simon Hausmann <Simon.Hausmann at qt.io>
Date: Friday, 9 December 2016 at 11:17
To: Friedemann Kleint <Friedemann.Kleint at qt.io>, Qt development mailing list <development at 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.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()

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 at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development