There are two separate things in there, though: the entry point and the construction of the Q(Core|Gui)Application object. The problem is with the latter: is it not clear why Morten’s proposal moves that under the framework’s control. Introducing a new entry point, e.g. qtMain(), for all platforms in Qt 6 is fine. Moving the application object construction into the underlying platform-specific entry point Qt provides is not.
Laszlo From: Development [mailto:development-bounces+laszlo.agocs=qt...@qt-project.org] On Behalf Of Filippo Cucchetto Sent: Friday, December 9, 2016 12:08 PM To: Lars Knoll <lars.kn...@qt.io> Cc: Qt Project Development Mailing-List <development@qt-project.org> Subject: Re: [Development] A new approach for Qt main() Does this relates to moving Qt main loop to a different thread other than the main thread? Cause currently creating the QtApp from a different thread causes problems. In particular the plugins static objects are destroyed at app exit and thus on the main thread (and this causes problems because QObjects should be freed in the same thread where they've created). An example is the QQmlComponentsCache. Il 09 dic 2016 11:44, "Lars Knoll" <lars.kn...@qt.io<mailto:lars.kn...@qt.io>> ha scritto: 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...@qt-project.org<mailto:qt...@qt-project.org>> on behalf of Simon Hausmann <simon.hausm...@qt.io<mailto:simon.hausm...@qt.io>> Date: Friday, 9 December 2016 at 11:17 To: Friedemann Kleint <friedemann.kle...@qt.io<mailto:friedemann.kle...@qt.io>>, Qt development mailing list <development@qt-project.org<mailto:development@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...@qt-project.org<mailto:qt...@qt-project.org>> on behalf of Friedemann Kleint <friedemann.kle...@qt.io<mailto:friedemann.kle...@qt.io>> Sent: Friday, December 9, 2016 11:00:00 AM To: development@qt-project.org<mailto: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<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org<mailto: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
