> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On
> Behalf Of Alan Alpert
> Sent: Wednesday, December 12, 2012 7:47 PM
> To: Sorvig Morten
> Cc: [email protected]
> 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
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
