some work and api design on plasma2

[Marco Martin]

On Thursday 19 July 2012, Aleix Pol wrote:
> 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...

well, right now what's in frameworks is a quite in between status that is not 
really working, so has to be brought in a state working without too many 
regressions.

but the most important thing is that kf5 is kinda the last chance for big 
incompatime changes, at least for a long while.

> 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

i think basically having two libraries, a libplasma and libplasmaqgv, with 
libplasma not depending from qgraphicsview.

an application linking to libplasmaqgv should maintain at least a good extent 
of source compatibility with current shells/applets.

that opens the possibility of having a libplasmaqml2 in the future, even tough 
on which i don't really want to think about yet ;)

for this basically is quite trivial for most classes, except the usual 
corona/containment/applet.

now i don't know how far from working is my branch, but i guess a quite scary 
amount of hours is still needed (and in which may not be trivial working in 
more than one person on it ;)

> the port. I might be able to dedicate some time on this, but I must
> make sure it's not a time drainer.

eh, that's quite a possibility :/


-- 
Marco Martin