[Development] Suggestion on QML portability

[Alan Alpert]

On Mon, 16 Jul 2012 09:38:53 ext Andreas Aardal Hanssen wrote:
> 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.

This is why I suggested a QtQuick 1.2 (not that you said whether that would 
help or not in your case), a version of QtQuick 1 which would work for the 
case of having code built against Qt 5 that's easier to work with between 
QtQuick 1 and 2. Since you'll still have to reprocess the import statements at 
least so I'm not sure what the big step up is.

> 
> 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.

The QML team discussed this and decided that it should not be done, and the 
reason is that re-adding them also causes pain to the audience of the API. The 
current incompatibilities are obvious, the sort of thing that you run into 
immediately and can easily find out how to fix (or perhaps merely something we 
remember to write in the what's new page). The major version shift caused 
major changes to the implementation and you should not assume that the 
behaviour of the elements will be the same. Invisible pain is worse than 
visible pain, so workarounds for reimplementing lost QtQuick 1 methods are not 
going to be added.

Case in point, the Qt.inputMethod.show() function behaves differently to the 
openSoftwareInputPanel() function, in that the old function only took effect if 
the element it was called on had keyboard focus. I didn't even know about this 
behaviour change until I talked to the person who wrote the old function, so 
it really isn't that obvious.

Not to mention all the slight timing differences that I really hope don't 
matter, but some people don't like to spin the event loop ;) .

I agree this solution isn't great, but in order to have a proper solution for 
major version shifts you need it implemented from the previous version. So 
there will be some pain left in the QtQuick 1->QtQuick 2 transition. Hopefully 
it will be resolved in the QtQuick 2 lifetime so that 2->3 isn't as bad.
 
> In Qt 4 we added obsolete symbols for Qt 3, and this never caused any pain
> for anybody.

Not the anecdote I heard. I heard that people used it to say "done, ported to 
Qt 4!" when it really wasn't, it was just using Qt3Support. I also heard that 
there are still people using it and their pain was just protracted until we 
tried to drop it again in Qt 5.

But our Qt4Support library exists and is called QtQuick1. All the old symbols 
should be there, if you want to take the easy road to saying "done, ported to 
Qt 5!".

--
Alan Alpert