On Fri, Jul 20, 2012 at 2:47 AM, Alex Fiestas <[email protected]> wrote: > On Thursday 19 July 2012 21:18:50 Marco Martin wrote: >> anybody can think about technical problems about it that may be lurking? >> it may mean a release of the workspace that doesn't use completely >> frameworks, so both old kdelibs and the frameworks will have to be >> distributed for some time, may this be a problem? (but not avoidable >> probably) > Uh... please don't eat me :) > > Do we really want to support qgv? it is a super big chunk of code we will have > to maintain for, waht gain? > > Pros: > - Keeping compatibility > - Not having to port everything to QML before switching to frameworks > - ... ? > > Cons: > - Big chunk of code to maintain > - QGV dropped by Qt project > - People not porting to QML because QGV work. > - We will piss people off > > How difficult would be to support ? would be possible to keep supporting it > when QML2 come to play? > > Cheerz ! > > > _______________________________________________ > Plasma-devel mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/plasma-devel
Well, I really doubt we can do a proper QtQuick1 to QtQuick2 port anyway. They are the same language but very different beasts. Another thing we can do, is to make a plain of libplasma to Qt5 and then create libawesomething where API would be maintained where applies but wouldn't depend on qgv. libplasma+qt5 could serve as a system to adapt to a new API but that's all. When the new one can be adopted then libplasma can be considered as deprecated (like we consider nowadays qgv-based plasmoids). Aleix _______________________________________________ Plasma-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/plasma-devel
