[Development] 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 Alan Alpert
> Sent: Tuesday, November 20, 2012 1:41 AM
> To: <development at qt-project.org>
> Cc: Thiago Macieira
> Subject: [Development] QML Tooling Renames (was: Pending decisions on
> co-installation)
> 
> On Thu, Nov 1, 2012 at 1:47 AM, Knoll Lars <Lars.Knoll at digia.com> wrote:
> > Hi,
> >
> > after reading through the whole thread, here's my comments on the
> different parts:
> >
> > On Oct 30, 2012, at 9:47 PM, Thiago Macieira
> <thiago.macieira at intel.com> wrote:
> >> 2) QML tool names
> >> Kai raised the point that many of the QML 2 tools work for QML 1 too
> >> and maybe even for Qt 4's QML 1. We need confirmation on that as well
> >> as the willingness to keep them that way for one or two years at
> >> least. For the tools that work on both QML engines, we can drop the
> version number from their names.
> >
> > I think most things are now settled, the main remaining ones are the
> qmlviewer/qmlscene names. As Chris said, they do somewhat different
> things. qmlviewer for QML1 actually adds a 'runtime' object into the QML
> environment and does some other magic. qmlscene is just instantiating a
> QQuickView and then executing the qml. So I'd go for qml1viewer and
> qml2scene, but let's hear if Chris/Martin have any further comments.
> >
> > Btw, we had a discussion here in Oslo that it would be great to at some
> point have a real qml runtime available. Probably simply called 'qml' as well.
> But let's keep that for a separate mail.
> 
> I agree that the discussion of the 'qml' tool should be a separate thread. But
> the concept makes me like qml1viewer/qml2scene for the current names
> because it leaves clear room for the unifying 'qml' tool later.
>
> So far we seem to agree on the following convention: Tools for QML 1 only
> start with qml1, tools for QML 2 or greater start with qml2, and tools for
> QML 1 or greater start with qml[-0-9]? (no digit after the qml). Note that
> qmleasing/easingcurveeditor aren't strictly QML2 or greater compliant, but
> they generate a list of numbers for the custom bezier easing curve,
> introduced in QtQuick 2.0.
> 
> There are two points I'd like to add to the discussion. Firstly qmlbundle isn't
> really useful yet, I'd advocate moving it to the playground or somewhere
> outside the qtdeclarative module until it's done.

I've been wondering about this too. There's zero documentation of it right now, and I guess nobody still active here really knows whether the whole bundle idea works, or not. Note though that the 'bundle' also appears in public API, namely QQmlFile  , which features e.g. bundleDirectoryExists(),bundleFileExists(), bundleFileName().

Alternative: Keep it in the sources for now, but don't install it by default.

> Secondly qmleasing and
> easingcurveeditor really should be merged. They both generate custom
> easing curve strings for QtQuick 2 animations, just from different
> parameters. I'll start that change later today, so if that gets in first then
> there will be no need to rename easingcurve editor.

I remember talking to Thomas Hartmann (the one who wrote easingcurveeditor) about this a few months ago. AFAIR the purpose of the tools are somewhat different (one for easy importing of Photoshop easing curves or something alike, the other for something else ;) Thomas is ill today, maybe we can leave the big merging alone until he's back? Both tools aren't installed by default , so I don't think this needs urgent attention.

> There was also a suggestion that symlinks be added for the multiply
> compatible tools, i.e. that you'd have qml1min and qml2min as well as
> qmlmin so that it's really easy for the developer (just the one rule based on
> which version you're using). I like that idea, at least in the $prefix dir and not
> /usr/bin, but I think it should be considered
> *after* the current renaming as it's an optional extra.
>
> 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 ...

Regards

Kai