On Tue, Dec 11, 2012 at 4:44 AM, Alan Alpert <[email protected]> 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 > [email protected] > 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? _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
