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

[Alan Alpert]

On Tue, Nov 20, 2012 at 11:34 PM, Samuel Rødal <samuel.rodal at digia.com> wrote:
> 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.
>>
>> 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. 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.

The versioning of the language is completely separate from the
versioning of QtQuick. qml2scene could easily run QtQuick 3.0
applications even if it's not using the scene graph, we'd just have a
more complex implementation choosing what window to create (or leaving
it up to the QML to create a window). But because it's purely a
development tool there is little need to implement the complex
implementation when the informed developers can choose themselves
which binary to debug with. The core difference is using
QDeclarativeEngine vs QQmlEngine, (and thus
QDeclarativeExtensionPlugin vs QQmlExtensionPlugin, and other binary
breaks even for non-visual items).

The language versioning is not very explicit anywhere, and we're not
restricted from playing with it. However I strongly think that we
shouldn't break binary compatibility again until Qt 6. This would mean
that we'll use QQmlEngine for loading all QML and that effectively
locks us into major version 2 of the language. It does not lock us
into any major version of the QML imports, which can be further
developed at any pace.

--
Alan Alpert