[Development] QML engine C++ class renaming

[andrew.den-exter at nokia.com]

> On quinta-feira, 16 de fevereiro de 2012 14.56.08, Stephen Kelly wrote:
> > On Thursday, February 16, 2012 14:50:32 Olivier Goffart wrote:
> > > On Thursday 16 February 2012 13:39:14 lars.knoll at nokia.com wrote:
> > > > Well, it's working for the moment, so the question is where the
> > > > person comes from that is willing to keep it alive. Since we'll
> > > > keep BC after 5.0, the work would mainly be to adjust to changes
> > > > in private headers and internals.
> > >
> > > So if one wants to change the private header in qtbase while
> > > implementing a new feate, who is responsible to port QtQuick1? The
> > > one making the change, or the QtQuick1 maintainers?
> > >
> > > Because if it is the one making the change, then it becomes a burden
> > > for the developers in qtbase.
> >
> > Isn't the same true in the QML2 stuff?
> 
> Yes, it is more or less the same still.
> 
> It's a shared responsibility to fix those issues arising from changing of
> internal API. But the point is that there are people to share it with: the one
> who made the modification to the internal API in the first place and the
> person who understands the code that got broken.
> 
> In the absence of either person, it's a nightmare. Which is why I really don't
> want a release *at all* unless there's someone to work with when changes
> to QtCore do happen. I don't want another ActiveQt on our hands, one that
> is used by lots of people and using a lot more internal API.

Based on the effort required to port QtQuick1 from 4.8 to Qt5 it is isn't nearly as brittle as you're making it out to be.  The only real  incompatibilities have been due to changes in public API for input methods, accessibility which equally affected QtWidgets,, otherwise it's almost unchanged except for license headers .

As far as use of private API goes there's surprisingly little.  Excluding private object inheritance I've found uses QObjectPrivate , QMetaObjectBuilder, QBezier, QWidgetLineControl, QWidgetTextControl and a mostly the same but optimized in an incompatible manner copy of QStaticText that utilizes a few private text classes.  There's not exactly a high possibility of drastic change among those classes.

I'm not saying there won't be any maintenance burden, but it's not massively greater than a lot of other modules either.

Andrew