[Development] QML Runtime

[Koehne Kai]

> -----Original Message-----
> From: development-bounces+kai.koehne=digia.com at qt-project.org
> [mailto:development-bounces+kai.koehne=digia.com at qt-project.org] On
> Behalf Of Alan Alpert
> Sent: Wednesday, December 12, 2012 7:47 PM
> To: Sorvig Morten
> Cc: development at qt-project.org
> Subject: Re: [Development] QML Runtime
> 
> [...]
> It wouldn't include QtQuick2ApplicationViewer, but that's more because I
> don't think QtQuick2ApplicationViewer needs to exist. Looking at it right
> now, what it provides is
> A) A QQuickView (you could have just used a normal QQuickView, or started
> the file with Window {} and used a QQmlEngine)
> B) An adjustPath function which is used for finding the main QML file.
> I don't know why this is needed, especially given that it does nothing on
> most platforms.

It's there because there are different conventions on different OS where the .qml files should be (relative to the binary). E.g. on Mac its unter .app/Contents/Resources, on QNX it's app/native, on Android it's "assets:/" ...

> C) A different choice for the resizeMode (one that is arguably incorrect for
> desktop)
> D) Connecting Qt.quit() to qApp->quit()

E) Using the 'right' way to show the top level widget, which also happened to be OS specific: show() vs showFullScreen() vs showMaximized().

> D is actually the interesting one here because it's a feature you want when
> your app is written in QML, but not a feature that you want when your
> application uses QML just for certain parts. That level of application control
> can't be in the QQmlEngine, because then you can't use the engine to just
> load QML as a scripting language. There was the example in the import
> security thread of using QML for config files, for that usecase you don't want
> a config file to say Qt.quit() and terminate your app.
> 
> So maybe there's a need for a slight split between the 'generic QML
> runtime' and the 'application QML runtime'. The qml binary would run the
> latter, and most QML using C++ applications would use the former.
> I don't know which one the creator template would want to use, but maybe
> there's a case for adding a small QQmlApplicationEngine in QtQml which
> adds the application runtime aspects? Then a QML only application which
> needs a C++ wrapper for some reason (like they all do now) would just be
> QGuiApplication app (argc, argv); QQmlApplicationEngine("main.qml");
> return app.exec();
> 
> Would this allow us to get rid of the concept of the QtCreator templates
> throwing in their own general utility classes?

I'd love to see that! We sort of misused the wizard so far to keep the Qt cross-platform promise for OS specific and deployment issues where the Qt libraries do not offer a solution, but it would be of course even better if we can have this properly as part of Qt.


Regards

Kai