[Development] QtQuick1 (Qt4 and Qt5)

[Alan Alpert]

On Thu, Dec 27, 2012 at 4:30 AM, André Somers <andre at familiesomers.nl> wrote:
> Op 26-12-2012 23:33, Alan Alpert schreef:
>> On Wed, Dec 26, 2012 at 11:58 AM, Thiago Macieira
>> <thiago.macieira at intel.com> wrote:
>>> On quarta-feira, 26 de dezembro de 2012 20.38.58, Alberto Mardegan wrote:
>>>> Hi all!
>>>>     I've a few API additions to propose to the QML FolderListModel class,
>>>> which is present in three modules:
>>>> - Qt4/QtDeclarative
>>>> - Qt5/QtDeclarative
>>>> - Qt5/QtQuick1
>>>>
>>>> Of course, all changes should go to Qt5/QtDeclarative; but what about
>>>> the others? Is there going to be one more release of Qt4? If not, I
>>>> think it makes little sense to update Qt5's QtQuick1 module as well --
>>>> doesn't it?
>>>>
>>>> Just to be clear: I don't mind submitting the changes to all three
>>>> modules (on the contrary, it would be my preferred choice); but I want
>>>> to know if there is a point in doing that or not. :-)
>>> There will be no more feature releases in Qt 4.x, so I wouldn't add new
>>> features to it.
>>>
>>> Whether to add new features to QtQuick1 or not... I don't know. Some may argue
>>> that it should not get features that weren't in Qt 4 (like Qt3Support didn't
>>> w.r.t Qt 3), while some others may say it's a regular Qt 5 module and that, if
>>> your new features don't risk adding to the porting effort from Qt 4, it should
>>> be ok to add them.
>> I'd argue that it should not get features that aren't in Qt 4.
>>

> I'd argue that as long as QML 2 can't be properly mixed with Qt widgets
> (like a QML view in a widget) like you can with QML 1, QML 1 has a very
> valid use case on its own, even in Qt 5. AFAIK, QML2 can't support that
> use case yet.

QtQuick 2 aims to have that use case supported by Qt 5.1. Any new
features for QtQuick 1 would be also targeting Qt 5.1. I'm not sure
this argument works, because the new QtQuick 1 features probably won't
be released until after this use case is invalid.

> With that, it also qualifies to get (compatible) feature
> updates I think. It should of course not deviate from QML 2 and develop
> in other direction, but I think it would be nice to bring features
> introduced for QML 2 also for QML 1 when feasible.

There is a very strong backwards/forwards compatibility issue to
consider. Let's actually look at the distinction between QML 1 and QML
2. The QML language feature improvements, like singleton types, the
var type, and v8 integration, are all improvements to the language
that do not depend on QtQuick 2. By the above argument, they should
have been applied to QtQuick 1 so that the improved QML 2 can still be
used with widget scenes. However this would break the compatibility
requirements of "import QtQuick 1.1", where existing QtQuick 1.1 apps
need to continue working without modification due to a wide variety of
subtle behavior changes. Note that this means QML 2 has diverged from
QML 1 already, to say nothing of the differences between QtQuick 1 and
QtQuick 2 (which have also diverged in key areas).

The primary purpose of having QtQuick 1 in Qt5 is compatibility, that
your "import QtQuick 1.1" QML works *as before* when you switch to Qt
5. Work on QtQuick 1.1 which is not eligible for a Qt 4 patch release
is clearly unacceptable. The question of a QtQuick 1.2 is less clear,
but I'd still argue that it's better to fill the hole (we've only
established one so far ;) ) of QtQuick 2 rather than release a new
version of QtQuick 1 after QtQuick 2 is out.

--
Alan Alpert