[Development] Suggestion on QML portability

Andreas Aardal Hanssen andreas at hanssen.name
Mon Jul 16 09:38:53 CEST 2012


2012/7/16 Alan Alpert <alan.alpert at nokia.com>

> Just brainstorming here, what if there was a QtQuick 1.2 in Qt 5 which
> provided this overlap? It would have the old method marked as deprecated
> and
> the new form syntax available and would provide some form of interim
> overlap,
> without adding functions to QtQuick 2.0. Would that ease your porting?


Just to bring the point to the table, this isn't just about _porting_.
Porting from QML 1 to QML 2 is unfortunately not just a language update.
It's also about having to move to an OpenGL only rendering environment,
which makes QML 2 useless to some graphics projects. This is why QML 1 is
still around. This topic is just as much about sharing QML code between two
independent QML projects. I'm in this situation now. I have complex state
logic that I don't want to fork or branch out in two code bases.

QML 2 should re-add the obsoleted symbols where it has no penalty to the
main API. There is no reason not to, other than causing pain to the
audience of the API. The good thing is that such APIs can be added in 5.1
and even later. But not doing so will make it harder for people to make any
use of QML 2.

In Qt 4 we added obsolete symbols for Qt 3, and this never caused any pain
for anybody. Qt3Support was a well intended effort to either port classes
that were dropped from Qt 3, or to wrap those around Qt 4 classes that
provided the same functionality. Let's make use of the good experience this
was in Qt 5 as well.

-- 
Andreas Aardal Hanssen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120716/c8e03a40/attachment.html>


More information about the Development mailing list