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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel