[Development] QML engine C++ class renaming

[Alexis Menard]

2012/2/16 Stephen Kelly <stephen.kelly at kdab.com>:
> 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 <stephen.kelly at kdab.com> | 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
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>



-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil