On Thu, Feb 16, 2012 at 8:35 AM, Artur Souza (MoRpHeUz) <artur.so...@openbossa.org> wrote: > On Wed, Feb 15, 2012 at 11:17 PM, Alan Alpert <alan.alp...@nokia.com> wrote: >> >> Now the fact that the C++ APIs are being maintained as well, and in this >> somewhat drastic manner, for an obsolete major version... it's not the ideal >> case that QML versioning planned for. So we'll see how effective this >> approach >> is. But the ideal that we're aiming for is with QML versioning is that you >> choose to upgrade at an application level after the library version goes up, >> instead of being forced into breakage. That requires something like QtQuick >> 1.0 sticking around for a while. Hopefully the next major version won't need >> so drastic a rewrite. > > IMHO the big problem here is the maintenance cost of QtQuick1 as > Thiago pointed out. > > The internals are different enough from QtQuick2 that we may not give > it enough attention/work. And then we may have the same situation as > we had with qt3support: people using it and we wanting them to come to > the new code. > > As d3fault pointed out in his email, but the end of Qt5 we will have > much more people using QtQuick1 than we have now, because this is the > time they are *starting* to use QML. > > Maybe, as QML is young enough, the better strategy would be to just > stick with it's newer version. > > PS: I agree that it would be fantastic to have a backward compatible > module, I'm just trying to be honest with myself and realize that the > chances that it will not be properly maintained are huge :)
And then you end up people claiming QtQuick1 in Qt5 does not behave like QtQuick in Qt4 (which I'm sure it will happen). My two cents : We provided portability library like Qt3Support because the move to Qt4 was not trivial. The move from QtQuick1 to QtQuick2 is much easier. We kept QWidget because today there is not replacement for it in QML (the new entry point for GUI in Qt5) and because moving from QWidget to QML is not trivial even if we had desktop components. So I think we should remove QtQuick1, it's a can of worms we are creating. The porting effort from Qt4 to Qt5 is minimal and I believe (based on my own experience) that porting from QtQuick1 to QtQuick2 is quite easy (expect if you have classes inheriting from QDeclarativeItem). > > -- > ------------------------------------------------------- > Artur Duque de Souza > openBossa > INdT - Instituto Nokia de Tecnologia > ------------------------------------------------------- > Blog: http://blog.morpheuz.cc > PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net > ------------------------------------------------------- > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
