[Development] QML Runtime

[Alan Alpert]

On Tue, Dec 11, 2012 at 11:33 PM, Sorvig Morten <Morten.Sorvig at digia.com> wrote:
>
> On Dec 11, 2012, at 8:30 PM, Alan Alpert <416365416c at gmail.com> wrote:
>
>> On Tue, Dec 11, 2012 at 3:33 AM, Sorvig Morten <Morten.Sorvig at digia.com> wrote:
>>> Please bundle the QML runtime in a class that the app author can instantiate.
>>>
>>> This gives us the flexibility to handle platform differences and integrate with existing workflows. There can still be a "qmlscene"-like binary that would simply instantiate the class.
>>>
>>
>> Already done. It's called QQmlEngine.
>>
>> Seriously, the direction this discussion has gone makes me think that
>> the 'qml runtime' binary will be basically a vanilla QQmlEngine that
>> can load a component from a file (or from text input or whatever) with
>> some command line chrome around it. If you want to load the runtime
>> within your own C++ application it works *exactly* the same as before.
>
> I think the mindset is important: "everything needed as a part of the qml runtime goes into QQmlEngine". This would include QtQuick2ApplicationViewer which is currently generated by Qt Creator when creating a new project.

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

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?

--
Alan Alpert