[Development] Suggestion on QML portability

[martin.jones at nokia.com]

> On Behalf Of ext Donald Carr
> 
> > Not inside this tower ;) . But I wasn't talking about comparing to the
> > proliferation of an unreleased version. All the QtQuick 1 I've seen so
> > far is on the dead Symbian and Maemo platforms. Even if there were
> > many of those applications, how many are in continued development for
> > both the old one and living platforms?
> 
> Err, as we all know, none of these platforms really took off and the vast
> majority of Qt Quick usage is actually by people seeking a general purpose
> productive (performant) toolkit to use on Linux based devices. Our device
> eco-system never really came to full fruition, our wide spread general Linux
> toolkit dominance never flagged and makes us almost ubiquitous in certain
> segments like automotive and the set top box space. This spills over into
> other segments where you have hardware too crusty to run Android and
> licensing costs would be prohibitive.
> 
> Next time you are cursing your inflight entertainment system, you will
> probably want to start with cursing yourself.
> 
> I concur with Robin here in any case; It is really frustrating to see such
> evidently co-existable maintainable code scuttled by a handful of sed -e
> 's/foo/bar/g' arguments. It introduces entirely needless burden, and will
> result in your groupies maintaining bash scripts which are regularly used to
> remove the quills from their rumps.

Using the same codebase for QtQuick 1 and 2 is a losing proposition.  At first glance they look very similar, but there are many behavioral changes which are likely to affect all but simple applications.  The opacity changes are one example recently raised.  There have also been many bug fixes made in QtQuick 2 that were not made in QtQuick 1.  Some of those have surely changed behavior - the behavior of items inserted/removed before the first visible in a view has been made more sensible in QtQuick 2, for example.  QtQuick is a new technology, and we've taken the opportunity to fix some things with the major version change.  Providing a few deprecated properties glosses over the fact that they have diverged quite significantly and there is absolutely no expectation that a QtQuick 1 app will just work with import QtQuick 2.0.

> An ifdef mechanism to support the co-existence of differing import
> statements in otherwise identical code would also move QML out of the
> glorious into the sublime.

This is something we can look into for a later release.

Br,
Martin.