[Development] QML engine C++ class renaming

Alan Alpert alan.alpert at nokia.com
Fri Feb 17 02:19:21 CET 2012


On Thu, 16 Feb 2012 22:12:16 ext Olivier Goffart wrote:
> On Thursday 16 February 2012 21:14:07 Alan Alpert wrote:
> > On Thu, 16 Feb 2012 20:47:49 ext Olivier Goffart wrote:
> > > On Thursday 16 February 2012 12:26:50 Alan Alpert wrote:
> > > > The way QML compatibility is supposed to work is different from C++.
> > > > Even
> > > > for a minor version, you don't always just jump to the latest
> > > > version. Your application continues using the version it was
> > > > developed for until you choose to update it, deliberately, to a more
> > > > recent version (note that if the C++ library updates you may get
> > > > bugfixes transparently, this is primarily about feature
> > > > additions/changes).
> > > 
> > > This is a falacy!
> > > When you upgrade the runtime, you anyway run into compatibility issues.
> > > The application has been tested to work with the version QtQuick x.y,
> > > its bug have been work arounded or avoided.
> > > Now, you come with a new runtime, that pretends to still be load x.y,
> > > but still fixes bugs? but often, fixing bugs mean also introducing new
> > > ones, new bugs against which the application has not been tested.  And
> > > the bugs you fix have most likely been work arounded.
> > 
> > For bugfixes I meant the ones that were safe in this regard. E.g a bug
> > like "calling foo crashes qml" would get fixed but theoretically, a bug
> > like "flickable is always 10 too short" would be in a minor version so
> > that you could remove your +10 at exactly the right time.
> 
> So we have two problems here.
> 1) how do you leave the +10 in QtQuick 2.0 but not in QtQuick 2.1 with the
> same codebase?  you end up with lot of conditional like this?
> http://paste.kde.org/423326/
> Hello maintainence!
> 
> 2) so when the programmer update its 100+ files application to QtQuick 2.1,
> he suddenly notice some flickable don't have the right size. How many
> hours will he take of debugging to find out where to remove that +10
> ;-)

According to my theorizing, that's a much better solution than it just 
updating invisibly and suddenly noticing that some flickables don't have the 
right size. He can try taking the version down by one per file to quickly 
check if that fixes it, and he's much more likely to know that he bumped the 
version himself than that this device/distro bumped the version in an update 
last week.

> (What if you did not change the QmlImage properly in my example? what if
> you forgot to add the version condition?)
> 
> > > But why in QtQuick x.(y+1) must I change the import statement. Is there
> > > so many incompatibilities that will make porting so difficult?
> > 
> > Probably not. You'll probably change the import statement and it's
> > perfect. But you can check per application. And consider the two major
> > cases:
> > 
> > A) Major version change. Let's be honest, you'll be lucky if nothing
> > broke. This is where there are so many incompatibilities that porting
> > needs to be taken seriously (even if we try sometimes to keep it from
> > being difficult).
> 
> For major version change, I totally, agree.
> 
> > B) Minor version change. This just added some new features. If you don't
> > need to use the new features, just keep importing the old version and
> > it's fine. If you do need them, you signify that with an updated import
> > at the time that you update your code to use new features. Note that
> > because minor versions can add new features, it will always have the
> > possibility of adding symbols (suddenly, there's a myObject property on
> > this object and it shadows the one you were expecting to get from the
> > root object sort of thing).
> 
> The problem is that you have a 100+ files application, Are going to mix
> import statements?

Why not? If you need a bug fix in one part, but ListView now spaces in a way 
that ruins your app, import the v1.0 ListView in one file and the v1.1 in the 
others. This isn't unmanageable if you do it clearly, e.g.

import QtQuick 1.1
import QtQuick 1.0 as OldQuick

OldQuick.ListView{
}
ListView{//uses 1.1
}

> ...
> > once there
> > are distros that ship a different version of Qt. I may have seen qt 4.8
> > in a fedora somewhere, so this issue is just emerging. QML's approach
> > doesn't seem as good for supporting multiple Qt versions "at once", but
> > I'm not convinced that's the common case. (FYI: If you're making the app
> > a QML/C++ hybrid like you should then you can still use those #ifdefs...
> > but it's less than ideal.)
> 
> There is no #ifdefs  in QML

There are in C++, if you're using QML/C++ you can use C++ #ifdefs and 
propagate the effects to QML with relative ease (still less than ideal of 
course).

> > > Of course, the inconvinient is that C++ is a static compiled language,
> > > and then it needs to be compiled.
> > > 
> > > But with QML you artifitially have this problem because you need to
> > > pick you version.
> > 
> > We actually do a lot of that sort of thing in QML. JS is an extremely
> > dynamic language,
> 
> Yes, but the  "import Quick 2.0" is very static
> 

Exactly my point. QML ratchets the dynamism down a notch to make things easier 
to work with - for both the language and its users.

-- 
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks



More information about the Development mailing list