> -----Original Message-----
> From: development-bounces+kai.koehne=digia....@qt-project.org
> [mailto:development-bounces+kai.koehne=digia....@qt-project.org] On
> Behalf Of Jana Aurindam
> Sent: Thursday, October 18, 2012 7:15 PM
> To: Thiago Macieira
> Cc: <development@qt-project.org>
> Subject: Re: [Development] Summary of renaming changes
> 
> On Oct 18, 2012, at 5:30 PM, Thiago Macieira wrote:
> 
> 
>       After all of my patches are integrated, here are the changes that will
> happen:
> 
>       - bin:
>       The following tools have been renamed:
>       qmake -> qmake5
>       moc -> moc5
>       uic -> uic5
>       rcc -> rcc5
>       qdbusxml2cpp -> qdbusxml2cpp5
>       qdbuscpp2xml -> qdbuscpp2xml5
>       lconvert -> lconvert5
>       lrelease -> lrelease5
>       lupdate -> lupdate5
>       xmlpatterns -> xmlpatterns5
>       xmlpatternsvalidator -> xmlpatternsvalidator5
> 
>       qmlviewer -> qml1viewer
> 
> 
> This should be just qmlviewer (as it was in Qt 4.8).. I dont see a reason for
> this renaming..

I guess the reason is that there's already a qmlviewer - the Qt 4 one. If we 
also go with qmlscene ->qml2viewer, we'd have

qmlviewer -> qt4 
qml1viewer -> Qt 5, Qt Quick 1
qml2viewer -> Qt 5, Qt Quick 2

Not exactly intuitive, is it ? :( Also, what happens if we release a Qt 6 with 
a qml 2 compatibility viewer?

Thinking about it, I'd rather keep the qmlviewer, qmlscene names, and go for

qmlviewer -> qt 4
qmlviewer5 -> qt 5 , qtquick 1
qmlscene5 -> qt 5 , qtquick 2

> 
>       [qml1plugindump had already been renamed]
> 
> 
> This should be reverted back to qmlplugindump .. (Same reason as above..
> For QtQuick2, the related binaries can be renamed to qml2* (to reflect the
> version change)
> 
> 
> 
>       qmlscene -> qml2scene
> 
> 
> This should be qml2viewer.
>
>       qmlplugindump -> qml2plugindump

I have two problems with the 'qml2x' names:
 - It can be misread as a qml _to_ x converter tool
 - What happens if we have a QML2 compatibility module in qt 6? 

I think we should go therefore for following the names from the other modules, 
and just add a '5' at the end for tools that we probably cannot promise 
compatibility for in a hypothetical Qt 6. The only exception being 
qmlplugindump, because there are two versions of it even in Qt 5:

qml1plugindump5
qml2plugindump5

>       qmlbundle -> qml2bundle

qmlbundle5

(yes, it cannot be used with Qt Quick 1, but that's a documentation issue)

>       qmlmin -> qml2min

I'd be very surprised if qmlmin cannot also handle .qml files from QtQuick1 (Qt 
5 or Qt 4) -> can stay qmlmin.

>       qmlprofiler -> qml2profiler

qmlprofiler5

(yes, it cannot be used with Qt Quick 1 right now, but that's a documentation 
issue. If there's demand we could even make it compatible ...)

>       qmltestrunner -> qml2testrunner

qmltestrunner has an option to run with Qt Quick 1 -> can stay qmltestrunner.

>       The following tools require more information:
>       qdoc: not renamed because the Qt 4 version was called "qdoc3"
>       qhelpgenerator, qcollectiongenerator, qhelpconverter: they
> apparently
>       keep backwards compatibility, so they should replace the Qt 4
> versions
>       qglinfo: new tool from qt3d
> 
>       The following are user applications and they have not and will not be
> renamed:
>       qdbus
>       qdbusviewer
>       assistant
>       designer
>       linguist
>       creator
>       pixeltool
> 
>       - lib:
>       All libraries are now called libQt5Name.so.5 on Unix systems,
>       libQt5Name(_debug).5.dylib on Mac, Qt5Name(d).dll on Windows.
> This also
>       applies to the qmake .prl files, the libtool .la files and the 
> pkg-config
> .pc
>       files. The cmake files had already had the "5".
> 
>       EXCEPT in Mac Framework builds. Since the header search path
> takes the
>       framework's name, for source compatibility, the framework builds
> did not get
>       the "5" in the name.
> 
>       - include:
>       No change.
> 
>       - doc:
>       On Windows builds and on -no-prefix-install builds, no change.
> Otherwise, the
>       default install path is now $prefix/share/qt5/doc.
> 
>       Question: should it be $prefix/doc/qt5 to match autoconf's default?
> 
>       - mkspecs:
>       On Windows builds, on -no-prefix-install builds, and on builds with -
> hostprefix,
>       no change. Otherwise, the default install path is now
> $prefix/lib/qt5/mkspecs.
> 
>       - plugins:
>       The default install path is now $prefix/lib/qt5/plugins on all
> systems.
> 
>       - imports:
>       The default install path is now $prefix/lib/qt5/imports on all
> systems. It
>       applies to QML 1 and Qt Quick 1 only.
> 
>       QML2 imports go to "qmldir", which defaults to $prefix/lib/qt5/qml
> on all
>       systems.
> 
>       --
>       Thiago Macieira - thiago.macieira (AT) intel.com
>        Software Architect - Intel Open Source Technology Center
>       _______________________________________________
>       Development mailing list
>       Development@qt-project.org
>       http://lists.qt-project.org/mailman/listinfo/development
> 
> 
> 
>  --
>   Aurindam Jana, Software Engineer - Digia, Qt
>   Don't Panic!
>   Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
>   Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
>   Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to