[Qt-qml] import QtQuick 1.0

[Jason H]

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.

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

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 


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt.nokia.com/pipermail/qt-qml/attachments/20100909/9f7533e2/attachment.html