[Development] Suggestion on QML portability

Alan Alpert alan.alpert at nokia.com
Mon Jul 16 09:09:14 CEST 2012


While I continue the discussion to my usual level of verbosity inline, I'm 
bringing the important point up top - read it last to understand the thought 
process that led me to this:

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?

On Mon, 16 Jul 2012 08:20:23 ext Robin Burchell wrote:
> On Mon, Jul 16, 2012 at 2:02 AM, Alan Alpert <alan.alpert at nokia.com> wrote:
> > The theory is that you're not trying to maintain a single codebase for
> > both
> > QML1 and QML2.
> 
> The point has been made before, but I'll repeat it: for libraries and
> other pieces of middleware, that isn't really an acceptable answer. As
> a library author, I guarentee that you will get pushback, resistance,
> and hostility from insta-deprecating one release the moment you make
> another. Just like, for instance, Qt users would raise merry hell if
> we dropped Qt 4.8 at the same time as we released Qt 5.

Right, and we're not dropping QtQuick 1.1 at the same time we release QtQuick 
2.0.

> Now, that doesn't mean that it isn't possible to release based on two
> seperate codebases, but, the QML is more or less identical. So what
> does that gain me except a major pain in the ass in terms of making
> sure I merge branches, often? And that's assuming that all
> contributors are "well behaved" enough to remember that their
> contributions must go on both branches, etc, etc, etc.
> 
> I do understand that this isn't an easy problem at all, but when the
> price to pay is just marking some methods as deprecated - as opposed
> to completely removing them - isn't this a manageable pain in the name
> of "making things easy" for middleware authors? And after all, isn't
> one of the promises of Qt 5 that we have source compatibility mostly
> intact?
> 
> > Perhaps we just gave up because the significant behavioural
> > differences guaranteed that it would be a major pain no matter what.
> 
> Renaming methods is not a behavioural difference.

Are you saying that this renamed methods (and a switched import statement) are 
the only difference between your QML1 and QML2 codelines? I would have thought 
the behavioural changes would have already caused them to split. Certainly if 
you have any C++ visual elements they needed to be re-written for QML 2.

> 
> > But I don't understand why MeeGo components need to have a unified branch,
> > surely the first version using Qt5 uses QML2, the previous version uses
> > QML1, and they have to be on separate branches anyways?
> 
> You're assuming that there's a complete cutoff. That isn't the case
> for most middleware, and while it could be for our intended uses of
> components, it would hamper our ability to get things done: we'd have
> to port every QML application we have to QML2 instead of just doing
> them one at a time, as we please. And that also then means that every
> third party application using QML is forced to be QML2-only, likewise.
> That's not really acceptable given that the majority of MeeGo
> applications are QML1, and developed by a whole swarm of people.

The previous version could be maintained separately, like QtQuick 1 is in Qt5. 
Perhaps not the best example, but that's how it was planned for middleware. If 
Meego X has Qt 4.8 available it has QtQuick 1.0 and QtQuick 1.1 available. 
Then if Meego X+1 has Qt 5, it has QtQuick 1.0 and QtQuick 1.1 and QtQuick 2.0 
available, so that the existing MeeGo applications still work exactly the same 
as before until they feel like updating them (if ever). Because QtQuick works 
like this, I suspect other middleware (like MeeGo components) are dragged 
along with also having the same system.

One thing to consider for device middleware is that this was exactly one of 
the scenarios envisaged in the original design of QML versioning. The key 
aspect of this design is that after a system update previous apps work 
*exactly* as before without them having to update. Even some bugfixes lead to 
behaviour changes which break existing applications. So there is a cutoff 
point, 1.x receives critical updates only so that existing 1.x apps continue 
to work as before. Apps in continuing development get to update to 2.x at 
their own pace, although they need to in order to access new functionality.

This system was designed without consideration of other middleware, but it 
works if they follow the same system - MeeGo 1.a components need to become 
'done' for the existing QML1 applications to continue to work the same as 
before an update (although you could add a 1.(a+1) if you wanted; the entire 
1.x series doesn't have to be 'done'). So there's a split off branch already.

> 
> >> Is there really that much pain in having a deprecated
> >> closeSoftwareInputPanel method so I don't have to resort to somehow
> >> preprocessing the QML, for instance?
> > 
> > Yes, there is that much pain. At least that's my interpretation from the
> > example of Qt3Support. When do deprecated methods get discarded, if not
> > across major versions?
> 
> Ah, perhaps here is where we misunderstand each other. Can you point
> out when these were deprecated? Because they certainly weren't in
> 4.8[1], and there's no replacement for them there. Otherwise I
> wouldn't be complaining. My point is that they should have been
> deprecated first, at least until QML 2.1 or something, allowing one
> release of overlap (6-12 months) at least is probably sufficient for
> people to migrate given that QML is still a fast-moving,
> fast-developing technology.

Good point, because these were deprecated across a major version boundary 
there isn't actually any release with overlap. It also suggests a deficiency in 
the QML versioning system, because as it's developed there isn't an overlap 
period in this way. Minor versions tend not to deprecate API, and if they do 
they certainly won't remove it. So the only chance to remove API is in a new 
major version. It would not be easy to remove a deprecated method before 
QtQuick 3.0 (although we could do that in 6-12 months ;) ). Theoretically the 
overlap is instead in giving you time to wait before switching to QML 2, 
that's why QtQuick1 is still part of Qt 5.

--
Alan Alpert



More information about the Development mailing list