libplasma2: split anything

[Aaron J. Seigo]

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

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

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.

iow, we could have one scriptengine that does it either way, depending on what 
it is loaded by, or we could have two scriptengines and make those dependant 
on the type of Corona in use.

there are a number of ways of accomplishing this without exposing the details 
to the plasmoids or creating a mess of things internally. ideas: 

the Corona could  handle or influence loading of Applet/Containment script 
engines. we could, for instance, note in the ScriptEngine's .desktop file 
which "world" it belongs to (QML, QGV, etc.) and have them loaded based on 
what the Corona needs.

remember that the ScriptEngine not only represents a loading mechanism, but 
also an API provider and a sandbox. making the Corona the provider of all of 
that is likely impossible and certainly less future-proof as changing API or 
enforcing sandbox controls means doing it all in the Corona for all components 
simultaneously.

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

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

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

from a plasmoid creators POV, this makes no sense. this is just "magic glue" 
to make special things happen because there would be this hackish "two 
different sorts of plasma shells". pushing those kinds of details into 
Plasmoid implementations like this is really not good.

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

so tons of duplicated code to do exactly the same thing in both libraries. -1.

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

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20110706/d278ba17/attachment.sig