libplasma2: split anything

[Marco Martin]

On Wednesday 06 July 2011, Aaron J. Seigo wrote:
> On Saturday, July 2, 2011 16:30:27 you wrote:
> > On Monday 27 June 2011, Aaron J. Seigo wrote:
> > > On Sunday, June 26, 2011 19:25:08 Marco Martin wrote:
> > > 
> > > for a QGraphicsView based shell, it shouldn't really care, as i
> > > understand it. both can be popped onto the scene.
> > 
> > they can, but what i think it won't work is the following:
> > they have to have a common base class to work
> > but they can't inherit from qobject since both already are
> > so,
> > 
> > 
> > 
> > * are kde plugin base classes forced to be a qobject?
> 
> afaik, yes.
> 
> > * and, how much we need the base to be a qobject in libplasma? (same goes
> > for corona and containment)
> 
> not having them as QObjects means no properties, no signals or slots ..

yep, and this moves most of the implementations in the subclasses, exactly the 
kind of duplication you were talking about..

> > engine and qml scene where all applets would hook into, regardless of
> > their language, and a big part of the script engine would have to go
> > straight in that library (or a corona wouldn't work at all)
> 
> this, to me, sounds like an "implementation detail" from the POV of the
> plasmoid. the script engine should simply be able to "do the right thing"
> and either put the plasmoid into an existing QML scene or create one on
> its own for the QGV case.

yes, but in the case of the qml only shell, would be the corona that knows the 
global qdeclarativeengine and the various sg scenes i think...


> > in the light of this, i'm starting to think that the
> > applet/corona/containment triplet should have a completely different
> > implementation with no base class whatsoever,
> 
> in other words, implement libplasma twice. seriously?

yes, no, uhm, dunno. i'm so out of ideas on how to make a qobject Applet in 
which the old class can still be used that i'm not excluding anything atm :/

> > in the desktop files
> > Plasma/Applet, Plasma/Containment would mean things using the
> > qgraphicsview api, the qml ones would be something else like
> > lasma/Plasmoid
> > Plasma/PlasmoidContainer or any other name doesn't really matter.
> 
> so we'd be left with an non-interoperable split: things written in QML can
> not be used in a QGraphicsView environment, nor vice versa.
> 
> for this to work at all, we need to be able to migrate from mixed QML/QGV
> components to QML-only while maintaining a mixed shell (e.g.
> plasma-desktop) for some undefined period of time into the future.
> 
> otherwise, there is zero point in trying to do a split with a QML-
> specialization and a QGV-specialization. if the end result is a QML-only
> world and a QGV-only world, we're pretty well screwed as we can't use
> components already written (which means a huge amount of rewrites) not to
> mention we'd be screwing over the hundreds of people who have written 3rd
> party plasmoids already).
> 
> no, i really don't like the direction of this at all.

me neither, but i don't see any way that isn't a pretty hard split if we want 
to ever suppo scene graph (we can also say to continue with qgraphicsview till 
the end of the days, but won't be really maintained..)

in scene graph, anyways, is simply plain impossible to use anything that 
inherits qgraphicswidget/qgraphicsitem (heck, even qdeclarativeitem)

so, in any ways, there is no way to reuse components written in c++ that have 
anything graphical, that's just how scene graph is (internally they 
reimplemented all the qml primitive elements with the same exact api).

so while i agree 100% that this idea of having to maintain almost two 
implementations is completely nuts... i don't see big alternatives.


> > the only thing that depends from applet is every now and then classes
> > searching from the applet package or the applet plugin name, like Svg
> > doesn't look extremely difficult to make it working anyways (searching
> > them with a qproperty instead of methids?)
> 
> that sounds extremely ugly and hackish.
> 
> is this really what we want the next version of plasma to be? at least to
> me, this is not an acceptable future.

so, to recap, i'm sure there are still better options that haven't be seen 
yet, what we need is(?)

* a common base implementation of applet/containment/corona, at *least* 
QObject

* everything qgraphicswidget out of the main library, so the base applet not 
be one, iff we want to use scene graph

* existing c++ applets/shells as much as source compatible as possible

* cost/benefit of going scene graph or not, since the code that can't be used 
in there is a *lot*

i also tought about those classes being kind of "models" with just properties 
that would either contain or be contained in the actual graphical applets, but 
i don't really know how to load the plugins maintaining enough source 
compatibility with old applets...

Cheers,
Marco Martin