some work and api design on plasma2

[Aleix Pol]

On Thu, Jul 19, 2012 at 7:27 PM, Marco Martin <notmart at gmail.com> wrote:
> Hi all,
>
> as you know the hardest thing, by far in plasma2 is splitting anything related
> to qgraphics* out of libplasma.
> that basically means graphics-less Applet, Containment and Corona, and this
> will have to happen in time for frameworks5, regardless having a qml2 version
> ready or not (i would go as far as  putting that as completely secondary and
> eventually releasing it only in a second time)
> the quantity of work still to be done is huge, and the time not much.
>
> i have now a branch in kdelibs: plasma/mart/simpleapplet
>
> it's a branch of frameworks and had the following work:
>
> corona, containment and applet are for now disabled from build (libplsmaqgv
> that's the legacy qgraphics* library doesn't build atm)
> there are AbsrtactApplet and AbstractContainment: they are still not finished,
> but are intended to be qobject-only versions, with only the logic. all the
> other parts in libplasma that were depending from applet or containment are
> now using abstractapplet or abstractcontainment.
>
>
> problem: the old qgv based Applet and Containment should inherit from
> AbstractApplet and AbstractContainment, but this means abstract* cannot be
> QObjects, but they need some signals and slots (besides needing to be able to
> be loaded as plugins: required to be qobject?)
>
> so basically there are 2 options:
> a) abstractapplet/containment are not qobjects (exposing a qobject member for
> needed signals/slots? kinda ugly)
>
> b) make them qobjects and make Applet/Containment not a subclass but having
> abstractapplet as a member property, so that would become a sort of a "model"
> (kinda ugly as well)
>
> in both cases it may be needed and a completely separated implementation of
> Corona (that in turn poses the same problem, at the moment it has a partial
> separation to a CoronaBase class that is following the model b) approach, but
> can be changed)
>
>
> comments? suggestions? volunteers for the work? :p
>
> Cheers,
> Marco Martin
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel

Do we really need to have this for KF 5.0? It should keep working with
Qt5, so rushing could be a problem...

On the other hand, I agree that it's something we want to have stable ASAP.

It would be good if someone could step forward and organize a little
bit how this refactoring should happen and what would be the scope of
the port. I might be able to dedicate some time on this, but I must
make sure it's not a time drainer.

Aleix