[Development] QRE: QML Tooling Renames (was: Pending decisions on co-installation)

[Koehne Kai]

> -----Original Message-----
> From: development-bounces+kai.koehne=digia.com at qt-project.org
> [mailto:development-bounces+kai.koehne=digia.com at qt-project.org] On
> Behalf Of Samuel Rødal
> Sent: Wednesday, November 21, 2012 8:34 AM
> To: development at qt-project.org
> Subject: Re: [Development] QML Tooling Renames (was: Pending decisions
> on co-installation)
> 
> On 11/20/2012 05:05 PM, Alan Alpert wrote:
> > On Tue, Nov 20, 2012 at 8:00 AM, Jana Aurindam
> <Aurindam.Jana at digia.com> wrote:
> >>
> >>>> To summarize QML tool naming discussion so far:
> >>>>
> >>>> In qtquick1 repo
> >>>> qmlviewer -> qml1viewer
> >>>> qmlplugindump  -> qml1plugindump
> >>
> >>> That's already the name, isn't it?
> >>
> >>>> In qtdeclarative repo
> >>>> qmlscene -> qml2scene
> >>>> qmlplugindump  -> qml2plugindump
> >>>> qmlbundle -> move to playground
> >>>> qmlmin -> qmlmin
> >>>> qmlprofiler -> qmlprofiler
> >>>> qmltestrunner -> qml2testrunner
> >>>> qmleasing -> qml2easing
> >>>> easingcurveeditor -> qml2easing (merge tools)
> >>>>
> >>>> Does anyone have any further feedback on QML tool renaming before
> >>>> these get implemented?
> >>
> >>> I don't feel too strong about the particular names anymore. But if you're
> changing the names of especially qmlplugindump, qmlviewer, qmlscene, it
> should go in fast ! We need to fix Qt Creator then, too, and I >guess also a
> bunch of documentation ...
> >>
> >> I am quite against the renaming of binaries.
> >> Does qml2scene mean that there is an equivalent qml1scene?
> >> what is the difference between qmlviewer in qt 4.8 and qt 5.0 that a
> renaming is necessary?
> >
> > Differences between qmlviewer and qmlscene qmlviewer only:
> > -Renders QtQuick 1 scenes.
> > -Has some built in testing functionality -Has some additional
> > development UI (logger window, screen shots, and such) qmlscene only:
> > -Renders QtQuick 2 scenes.

The difference in the feature set is something that just happened, and I could imagine that qmlscene gets some features back over time. The key to me is that people are using the tool for the exact same purpose : pre-viewing  QML files. That's why I originally proposed qml1viewer, qml2viewer.

> > If the names are left as they are, it's not entirely clear which to
> > use in your development. qml1viewer for qml1 and qml2scene for qml2
> > makes this fairly clear.
>
> One core difference is that qmlviewer uses QDeclarativeView and qmlscene
> uses the scene graph. 

Well, actually qmlviewer uses a QDeclarativeView that's based on QGraphicsView framework, and qmlscene uses a QQuickView that's based on scene graph (QSG*) :) So it's a bit more convoluted, and I don't think most users will intuitively grasp the connection , let alone really understand the relations between QML, Declarative, qtdeclarative & qtquick1 folders, QtQuick 1, Qt Quick 2, [QtQuick]SceneGraph, QGraphicsView ... In Qt Creator at least we're moving more and more towards using 'Qt Quick 1' and 'Qt Quick 2' to differentiate between both stacks. So there's e.g. a 'Qt Quick 1 Application Template', and a 'Qt Quick 2 Application Template'. If qtquick1previewer wouldn't be such an awful name it would have my vote ;)
 
Anyway, it's just names, and it seems most people don't mind to much, whatever it's called.

> I presume that if we did a QtQuick 3.0 it might still
> use the scene graph, and thus we'd still use qmlscene to run QtQuick 3.0
> applications. Or do we want to end up with qml3scene, qml4scene, etc?
>
> Or, is the versioning of QML, the language, completely decoupled from the
> versioning of QtQuick, the set of basic components and enablers for UI
> development? If so I guess it makes sense that qml2scene could still run
> QtQuick 3.0 applications if that would still use version 2 of QML.
> We're not very explicit about the language versioning in code nor in
> documentation though.

I think it's futile to speculate how QtQuick 3.0 will look like. Will it be just a new namespace / items, a new library, a new QML language, a complete new stack? Will it be part of Qt 5.x or not? I think nobody knows, and if the worst case happens I think adapting tool names during Qt 5.x lifetime is an option.
 
Regards

Kai