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

[Thomas Senyk]

On Wed, November 21, 2012 07:59:54 AM Koehne Kai wrote:
> > -----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 ;)

+1
IMO this is the technical correct term! 
(at least until "qtquick1", the rest is debatable)

The language (qml) is not changing between QtQuick1 and QtQuick2


The alternative is to define the name by engine/runtime used, this would result 
in: 
 - qmlview[er] (as in QDeclarativeVIEW)
 - qmlscene  (as in QQuickSCENE)

;)


> 
> 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
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development