[Development] A new approach for Qt main()

[Jake Petroules]

Without getting too much into the technical details, I'm all for it in principle. It would certainly help on iOS especially as there's a lot of complexity for the main() situation there, which is made even worse by trying to support dynamic libraries.

Can you give an example of what the definition of QT_GUI_MAIN would look like and what are the signatures of appInit and appExit?

> On Dec 9, 2016, at 1:35 AM, Morten Sorvig <Morten.Sorvig at qt.io> wrote:
> 
> Hi,
> 
> We should consider changing the way Qt initialization and startup works.
> This is something I’ve personally been wanting to do for some time, and
> a recent offline discussion pushed it on my stack again.
> 
> Currently, Qt and application startup looks something like this:
> 
>  int main(int argc, char **argv)
>  {
>      QApplication app(argc, argv);
> 
>      // Create root user objects/windows here
> 
>      return app.exec();
>  }
> 
> This is fine for the application but cause problems for the Qt platform
> implementation, which include:
> 
> * The main entry point may be named something else than main()
> 
> * The main entry point may be a callback which must be returned from
> 
> * The platform/Qt/application initialization order is incorrect
> 
> These have all been worked around in Qt platform code, for example by running
> Qt on a separate thread, using setjmp/longjmp to simulate a stack, or by
> temporarily setting up the native event loop before app.exec() is called.
> 
> We can continue with the workarounds, but they lead to complications in Qt
> platform code and are also an extra hurdle for implementing support for new
> platforms, so from the Qt platform development point of view it is desirable
> with a cleanup. 
> 
> This would be an “all applications should/must port” event, not to be taken 
> lightly. I think the porting would be trivial in many (if not most) cases,
> but some apps have special requirements for QApplication object management
> or main thread ownership. This includes our own QTestLib.
> 
> As a starting point for a concrete API discussion I’ll briefly describe the
> solution I implemented for the NaCl port. The user API here is a macro which
> takes application init and exit callback functions:
> 
>  Q_GUI_MAIN(appInit, appExit);
> 
> The use of a macro allows Qt to inject a main() call with native platform
> initialization code into the application, if needed. The init and exit
> functions are callbacks (which must return) and the root user objects
> must be created on the heap. The QApplication object is managed by Qt
> and has been created by the time appInit is called. The type of QApplication
> is decided by the macro, where there are CORE and WIDGETS variants as well.
> 
> - Morten
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Jake Petroules - jake.petroules at qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io