some work and api design on plasma2

[Aleix Pol]

On Fri, Jul 20, 2012 at 2:47 AM, Alex Fiestas <afiestas at kde.org> 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
> Plasma-devel at kde.org
> 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