On Mon, Jan 14, 2013 at 7:12 AM, Koehne Kai <[email protected]> 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
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
