[Development] QML Runtime

[Alan Alpert]

I'd like to remind people that qmlviewer and qmlscene are not meant
for deploying applications. They are not a complete runtime, they are
only meant for debugging. But the fact that people keep wanting to use
them for their applications suggests that it might be worth providing
a complete runtime. So I'd like to start the discussion about what
would suffice for qml to have a complete runtime. I'll go through my
initial vision for what it might look like in this mail. Comments are
welcomed, easiest would be to reply inline with comments if you don't
like any of my assumptions or if you have an idea for an improvement.

Goal: "qml" application. Something you can use like "qml main.qml" on
a linux system, or "./main.qml" where main.qml starts with
"#!/usr/bin/qml". I have no idea how this is supposed to work on
windows or mac, but I'm sure there's some equivalent :) . Basically
the idea is to be usable like other scripting language runtimes e.g.
perl, python, mzscheme (but not providing an interpreter shell... in
the first version at least).

qmlscene works almost like this already, so some people might think
we're already there. But I think qmlscene should stay as a debugging
tool and develop along a different path [1]. qml can be developed as a
separate tool, possibly even outside the qtdeclarative repository.

One big difference would be less flexibility about the invocation. As
a debugging tool qmlscene needs to be able to run smaller "units" of
QML to simplify debugging, that's why it just puts the top-level item
into a QQuickView. While that works for a lot of cases, it's not
really application behavior. qml should leave the window entirely up
to the application, meaning that the root item of any GUI application
would be a Window{} or similar. Note that this restriction would never
fly in qmlscene, because qmlscene needs to be able to run the
components of an application (like the inside of your Button.qml) to
debug and test them in isolation. This additionally gives the
advantage of no excess QQuickView when running a non-gui QML app
(which isn't really an issue for debugging, but sucks for deployment).

With this simplicity perspective in mind, here are my proposed command
line arguments for qml:
  --verbose (-v)  Print warnings to stdout (otherwise warnings are ignored)
  --version       Display version information
  --              End arguments for qml, remaining command line passed
to program (access to argc/argv should probably be added to QtQml
first)

Note that -I from qmlscene is not included (actually, there is no
overlap aside from an implicit --help). The import paths used by qml
should be the standard import paths plus a different system wide
location used for the installation of third party modules. This should
not then need to be altered for the deployment of the vast majority of
applications (remember that "." is a standard path to check for
imports). Here's a deployment example, for some versions of GNU/Linux:
an application pacakge could be installed into /usr/share/apps/MyApp,
and install a launch script to /usr/bin/MyApp just containing
'/usr/bin/qml /usr/share/apps/MyApp/main.qml'. Then the application
loads its remaining content relatively, plus installed modules it
might have a dependency on (depdencies handled by the package manager
of course).

Later on it would be nice to get the ability to feed it QML from stdin
or the command line, but that's not a critical feature.

There was also some discussion about exposing some additional
functionality to scenes run inside the runtime, but after thinking
about it I am now of the opinion that it should not expose extra
runtime functionality (like a runtime object) itself. Take the runtime
object in qmlviewer, whose two properties were orientation (now in
QtQuick.Window) and whether the application is active (now in the
global Qt object). Especially when viewed in the light of controlling
available QML functionality (like in the related import control
thread), all functionality should be exposed through QML modules. Note
that this doesn't have to mean QtQml and QtQuick, although they're
likely to have functionality of general importance to all users of the
runtime. By the way,
https://bugreports.qt-project.org/browse/QTBUG-13351 shows this
discussion is pretty old ;).

So does this simplified idea cover all bases, and all ideas of what
using QML runtime should look like? Would anyone use a qml like this
(if it was available on the system, like the system qt) to deploy
their application?

The other possible aspect this discussion could cover is packages
support in QML, like the future iteration of the qml bundle support
prototyped in QtDeclarative now, or something more like the packages
that Plasma Active uses for their QML. My assumption is that the
initial runtime is a pre-requisite for having that discussion, but
there's a definite need to think about that too - especially if it
would impact the design of the runtime.

[1] Which is important because a lot of these features would hamper
its ability as a generic qml debugging tool. It would also be nice to
bring back debugging features like qmlviewer has (like its extensive
menu and its command line options), but all this needs to be
coordinated with the puppet/observer processes in creator (a separate
topic which I'll let someone else start ;) ).

--
Alan Alpert