[Qt-qml] import QtQuick 1.0

[Jason H]

Oh, ok, thanks!

Also, I was doing some thinking, if you make the declarative engine, separate 
from QML (QtQuick) then you can re-leverage the declarative engine for other 
things, like say, web-pages.

Imagine having 'QtFormat', where the objects, instead if 2d images and 
animations, are data structures and transforms. Here's my brainstorm:
For Dynamic WebPage creation:
Elements:
Database  (provides a query interface) 
Formatter (base class for XML, XHTML, and BinaryFormatter)
XMLFormatter (for XML, XHTML)
BinaryFormatter (image generation, etc)

Resuse data models from QtQuick as parameter inputs.

Connect it to a socket, and you have a web server that runs a backend of C++, JS 
and CSS. 






----- Original Message ----
From: "henrik.hartz at nokia.com" <henrik.hartz at nokia.com>
To: scorp1us at yahoo.com
Cc: aaron.kennedy at nokia.com; qt-qml at trolltech.com
Sent: Fri, September 10, 2010 8:52:18 AM
Subject: Re: [Qt-qml] import QtQuick 1.0

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>