[Development] QML Runtime

Tue Dec 11 09:44:10 CET 2012

On Dec 11, 2012, at 9:34 AM, Mark <markg85 at gmail.com>
 wrote:

> On Tue, Dec 11, 2012 at 4:44 AM, Alan Alpert <416365416c at gmail.com> wrote:
>> 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).

+1 from my side (as we already discussed in San Francisco last week).

The qml runtime should not automatically create any Window. Basically all it should do is to instantiate a QML engine and then load the file given on the command line into it.
>> 
>> 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)

Sounds good. Command line access would be a good addition to QtQml.
>> 
>> 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).

Yes, that would work IMO.
>> 
>> 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 ;).

Another +1 from me. Actually I am strongly against any non standard API being exposed in the runtime. Everything has to come from QML modules that are being loaded through explicit import statements.
>> 
>> 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?

IMO it'll cover what we need. It might expose a few missing APIs in our existing QML modules, but let's fix these then when we find them.
>> 
>> 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.

I am not quite sure whether that would impact the runtime. IMO this is to a large extent an implementation detail, at least for the users of the runtime. People developing modules might have to (or want to) deal with this, but I do see packages mostly as an optimised format for deployment.
>> 
>> [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
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> 
> Ohh.. qmlviewer and qmlscene are not runtimes? I didn't know that.
> Then how are we supposed to deploy QML based applications right now in
> Qt 4.8.x?

You can use qmlviewer and qmlscene to launch and deploy apps. What Alan is saying here is that both apps have additional functionality and make certain assumptions (like implicitly creating a scene) that make them unsuitable as a generic runtime for QML.

Cheers,
Lars