[Development] QML Runtime

[Alan Alpert]

On Mon, Jan 14, 2013 at 7:12 AM, Koehne Kai <Kai.Koehne at digia.com> wrote:
>
>...
>
> So your idea is to consolidate on one qml binary, effectively deprecating qmlviewer and qmlscene? Sounds like a plan. I don't think we've 'deprecated' binaries in Qt before, but I personally don't see a big problem even removing them from one version to the other (as long as e.g. Qt Creator get's enough time to handle this gracefully from an IDE perspective). If we're nice we'd keep the binaries around for 2 minor versions or so ...
>

qmlviewer is deprecated anyways, because it's using the old
declarative engine. I should have clarified that the qml tool supports
QtQuick 1 only insofar as if QtQuick 1 gets ported to QML 2 it would
need a new binary to run it (and the qml tool could support that,
instead of a qmlviewer2). I really think we want to deprecate QML 1
even if there is a continued need for QtQuick 1 (which as already been
debated elsewhere).

The main scope for consolidation is forward looking. qmlscene was
needed as a separate binary for an implicit scenegraph canvas,
different from the implicit canvas of qmlviewer. I'd like to see the
canvas made explicit, so that you don't need a different qml binary
for running a different QML file. We now have that explicit canvas
with the Window{} item, but only recently did qmlscene gain the
capability of running with a Window{} root item! qmlscene still has a
lot of SG specific functionality, and I don't think we should force
anyone using their own module to have to write their own qmlscene
equivalent. We certainly don't want people to deploy non-QtQuick2
applications with a binary that's filled with QtQuick2 only
command-line options.

The original idea was to try to separate the binary for launching a
full application and the binary for testing a partial application (the
main difference being the implicit root item, other differences
including the debugger and dummy data files). Since you've convinced
me that it's better to have a single binary, I guess I'll look into
adding the same debugging support to the qml tool. But it would still
lose some QtQuick 2 specific functionality (of which, all but
--slow-animations should be on Window{} ), and I still think the
conceptual difference warrants the new binary (which is now closer to
a name change).

--
Alan Alpert