QtCS2015 QML Runtime
The QML runtime session explained the existence and rationale for the QML runtime (qtdeclarative/tools/qml).
The rationale is that it is more generic than just qmlscene, yet is configurable to have the same level of convenience for QtQuick (among others). It has a runtime configuration file which can identfy a partial QtQuick scene and wrap it in a simple Window, actually part of the sources and bundled via QRC. The configuration file could be extended for other partial scenes, such as if Qt3D wants to wrap a simple viewport/canvas around any Item3D{} partial scene. As it's loaded at runtime, this would not add any dependencies on Qt3D for the qml binary.
Given the rationale, there was talk of fully replacing qmlscene to avoid duplicated maintenence. This would require at least
- Fixing all the docs that still point to qmlscene (everywhere)
- Using qml instead of qmlscene in QtCreator
Anything else need to be done before we can deprecate/replace qmlscene?
There is discussion of extending the QML runtime configuration file to include configuring options. The concept is that you could use this to have a custom -help if your running your own executable, or that you could remap the arguments so that qmlscene could be a specially configured invocation of the QML runtime (while maintaining compatibility with all CLI arguments).
There were also some questions about whether certain arguments really belonged there. It might be possible to hide them, maybe even with a developer configuration file, but others (especially the ones we didn't implement from qmlviewer) could be implemented via a "shell" QML application. An example of such an application might be useful to add to the examples directory.
A final point about the configuration file, is that we'll need an easy way to extend it (especially if we use it to customize options in certain invocations). The idea I have so far (thought up after the session) is that the configuration file, or individual types in it, gain a "supplemental" property. If that is set on the file, then it will continue the search for configuration files (in the same order as dfined already) and add their configurations as well. Common case for that would be a custom config file which wants the built-in as well, perhaps even built-in + user settings. That still leaves the problem that wrappers with custom options will need to have a path to a deployed conf.qml file which has supplemental set on it, so they can pass that to -f in their #! line.