On Dec 11, 2012, at 9:34 AM, Mark <[email protected]> wrote: > 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).
+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 >> [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? 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
