2012/2/16 Stephen Kelly <[email protected]>: > On Thursday, February 16, 2012 08:43:37 Alexis Menard wrote: > >> 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). > > > > ... in which case the effort is not minimal. :) > > > > So look beyond the one-dollar-apps. Is it a common thing to do to have > hybrid QML/C++ applications? (The answer is yes). > >
Having lot of QObject classes is ok, that would still work. I was talking about sublclasses of QDeclarativeItem. I looked in kde-baseapps kdeedu kdegraphics kdelibs kdepim kdepimlibs kdepim-runtime kdeplasma-addons kde-runtime kdeutils kde-workspace and there are 14 classes inheriting from QDeclarativeItem. I believe quite a lot could use the non optimal QQuickPaintedItem to be ported quickly. > > I don't know how this problem will be resolved. I don't like the idea of > keeping QtCore internals static and not making performance gains in Qt5.x > because qtquick1 uses the old stuff. > +1 > > > It's quite similar to the current qmetaobject revisions situation where now > qtactiveqt is being updated. QtQuick1 would have to be maintained, but > presumably no one is stepping up to do that. > > > > Thanks, > > > > -- > > Stephen Kelly <[email protected]> | Software Engineer > > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > > www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 > > KDAB - Qt Experts - Platform-Independent Software Solutions > > > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development > -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
