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.sor...@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@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development