[Development] QML Runtime

[Mark]

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?