[Development] [QtCS] QML Runtime Session Summary

[Alan Alpert]

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.

--
Alan Alpert