On Thursday 19 July 2012, Aleix Pol wrote: > On Thu, Jul 19, 2012 at 7:27 PM, Marco Martin <[email protected]> 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 > > [email protected] > > 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 _______________________________________________ Plasma-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/plasma-devel
