[Development] QML Runtime

[Ziller Eike]

On 11.12.2012, at 09:34, 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).
>> 
>> 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
>> _______________________________________________
>> 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?

I suppose one way to do it, is to take what the "Qt Quick Application" wizard in Qt Creator creates.

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B