[Development] QML engine C++ class renaming

[Thiago Lacerda]

I think that maintaining the QtQuick1 in Qt5 will make people
become accommodated with the old technology (those people who have apps
relying on QtQuick1)
instead of adopting QtQuick 2 for their new applications (why spend time
learning the new features of QtQuick2 if 1 is still working on Qt5?), as
happened with qt3support.

Additionally, those people allocated to maintain QML1 could spend their
time thinking about new features, things that were done erroneously in QML1
and make them better, improving QtQuick2.

As Alexis has pointed out, porting an application from QML1 to 2 isn't
that painful.

That's my two cents.

Cheers

On Thu, Feb 16, 2012 at 11:42 AM, Thiago Macieira <thiago.macieira at intel.com
> wrote:

> 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.
>
> Also note that there are plenty of strict-aliasing violations pointed out
> by
> the compiler today in the QtDeclarative 4.8 code. It's to be expected that
> new
> versions of GCC *will* cause breakages. Who will fix them?
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
>     Intel Sweden AB - Registration Number: 556189-6027
>     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>


-- 
Thiago de Barros Lacerda
OpenBossa - INdT
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120216/fdd6d05b/attachment.html>