On 2016-12-09 04:35, Morten Sorvig wrote: > 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(); > } > > 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.
One concern I have is if users are monkeying with argc/argv prior to constructing a QApplication instance. IIRC, KDE used to do this (not sure if they still do), and qtCliArgs¹ does this also. This allows, for instance, enforcing a consistent argument naming policy that differs from Qt's own policy, while still being able to pass Qt CLI arguments. Also, how does this work if someone wants to subclass Q*Application? (Again, I have projects that do that...) (¹ https://github.com/Kitware/qtextensions/blob/master/core/qtCliArgs.h) -- Matthew _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development