libplasma2: split anything

[Marco Martin]

On Monday 27 June 2011, Aaron J. Seigo wrote:
> On Sunday, June 26, 2011 19:25:08 Marco Martin wrote:
> > now, when we do loadApplet it would be loaded this new thing, and the
> > trick unfortunately is just moved on how to selectively create a qml
> > object tree (and eventually load a c++ plugin on a Plasmoid* subclass)
> > OR load instead the old plugin of Applet* implementation

in the branch now an Abstractapplet that is just a qobject, from which i 
understood some things:

> when the plugin is loaded, the reulsting object should be a subclass of the
> new Applet, which would be either a QML item or a QGraphicsItem.
>
> 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?
* and, how much we need the base to be a qobject in libplasma? (same goes for 
corona and containment)
 
> for a QML-only shell, it will just need to discard any QGraphicsItem
> entries. it can also filter on the X-Plasma-API entry.
> 
> i suppose the Big Question then becomes: will we support QML applets
> written in C++ (which then export their QML root time via some API)? if so

a specialized api not needed, alll their properties/slots would just become 
available

> then we'll probably end up needing to add X-Plasma-API= entries to even
> the C++ widgets that are implemented in QML, and a special api name for
> it, e.g.
> C++Declarative that Applet can treat as "regular C++". then the C++ QML
> Applet subclass would need a virtual method by which to return the root
> item, which seems a bit messy. thoughts?

another thing is, since the qml based library would have only one way to have 
anything on screen, that is qml, the concept of the qml script engine really 
doesn't work anymore, since there would a single big qml 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)

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 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.

a qml only one could maybe still have Plasma/Applet,Plasma/Plasmoid to be kept 
working with both.

all what depends from Applet, like pluginLoader,AppletScript would have 
specialized implmentations in the specialized libraries.

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?)

-- 
Marco Martin