[Qt-qml] import QtQuick 1.0

[henrik.hartz at nokia.com]

Hi Jason,

On Sep 10, 2010, at 7:09 AM, ext Jason H wrote:

> I feel strongly about every issue, but this one more strongly than others.
> 
> Qt has expanded immensely since I started using it back in 3.x days. The functional scope is immense, the platform scope is immense and this leads to "glacial" release pace.
> 
> I am of the opinion that Qt needs to be divided into the main libraries and maintained seperately:
> Qt
> QML
> Mobility
> WebKit
> 
> This is facilitated by Qt's clean interfaces and plug in architecture. The change you describe only reinforces and echos this. 
> 
> I was very disappointed (remember I feel strongly about every issue) to hear that Blur and DropShadow were cut from the 4.7 release, with intent to add them back in.

They were just not exposed to QtDeclarative, you can easily re-enable them from C++ as mentioned in http://lists.trolltech.com/pipermail/qt-qml/2010-April/000224.html

> I think separating QtQuick out would help Qt be released sooner (less scope in 'Qt'), as well as QML enhancements. I think QML being so new, like mobility, needs a faster, independent release cycle, at least until things settle down.
> 
> Really I think we're seeing 'Qt' become an umbrella product brand rather than a library.
> 
> 
> 
> From: "aaron.kennedy at nokia.com" <aaron.kennedy at nokia.com>
> To: qt-qml at trolltech.com
> Sent: Fri, September 10, 2010 12:48:22 AM
> Subject: [Qt-qml] import QtQuick 1.0
> 
> Hi,
> 
> Currently all the core QML elements are in the “Qt” namespace, and the namespace’s version is coupled to the Qt version (eg. 4.7).  In retrospect we think this was a mistake.  And by “retrospect”, I mean “we always knew this was a mistake but we never got around to fixing it”.
> 
> For Qt 4.7.1, we are considering introducing a new namespace - “QtQuick 1.0”.  Although this breaks with Qt’s traditional definition of patch releases, it has the benefit of essentially decoupling the QML and Qt release cycles, which is especially important when you consider Qt’s recent glacial release pace.  Doing this means that we have the option of introducing new QML elements or properties in patch releases of Qt, rather than being forced to wait until a minor release to fix omissions or errors.  For example, Qt 4.7.2 might include “QtQuick 1.1” that could contain GestureArea.  If we think the Qt 4.7 series is going to be around for a long time, I think that the ability to do this is essential.  QML is quite tightly dependent on the rest of Qt, so an alternative strategy like we are using for webkit (ie. literally decoupling the releases) wouldn’t work.
> 
> It is important to highlight that this wouldn’t break any existing QML applications that were written against Qt 4.7.0.  “import Qt 4.7” would continue to work exactly as it always has.  Of course, a QML application written against Qt 4.7.1 might not work against Qt 4.7.0.  I think this is a “sacrifice” worth making.  
> 
> If we made this change, we would obvious add an explanatory note to our documentation for those who have started with Qt 4.7.0, but we would remove all other mentions to the fact that “import Qt 4.7” ever worked – all the documentation, examples and demos would be updated to use “import QtQuick 1.0”.
> 
> Does anyone feel strongly about this issue?
> 
> Cheers,
> 
> Aaron
> 
> <ATT00001..txt>