some work and api design on plasma2

[Marco Martin]

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