On Thu, 24 Sep 2009 22:07:31 Marco Martin wrote: > On Thursday 24 September 2009, Alan Alpert wrote: > > On Thu, 24 Sep 2009 20:38:16 ext Marco Martin wrote: > > > On Thursday 24 September 2009, Alan Alpert wrote: > > > ... > > > > > > i'm compiling the branch right now, then i'll be able to give more in > > > depth look. > > > > > > just quickly looking at it 2 things comes to my mind: > > > -in the qml the word Plasmoid is used for the main applet. technically > > > it indicates more the packages of scripted plasmoids that can contain > > > the code, the desktop file, the graphics etc.. could even make sense > > > there but maybe PlasmaApplet would be more correct? > > > > Could be. I had the feeling though that we didn't want to use the word > > 'Applet' outside of code. The issue here is whether QML files are code - > > I like to think of them as less code like and fully accessible to > > non-coders (and I'm probably being overly optimistic). If we view QML at > > the same level as the other scripting languages though then I agree with > > you. > > yeah, good question, let's wait other opinions on that ;) > > > > -most important: KineticApplet subclasses Applet, but plasma applets > > > can subclass also Containment and PopupApplet, that are in turn Applet > > > subclasses, in particular i think about 90% of todays applets are > > > PopupApplets, so it should be possible to use it for different types, > > > that wouldn't be possible subclassing just KineticApplet. > > > A solution that comes to my mind is, (even if still keeping the > > > scriptengine to do applets -just- with qml) making a widget that will > > > contain more or less the code kineticapplet contains, but usable inside > > > normal applets (that could or could not have other standard imperative > > > code or other widgets in a normal layout, together that one) this would > > > make it yes, more tricky but way more powerful. > > > > Hmm, so you are suggesting a QGraphicsWidget subclass instead? It would > > mean that, in the basic case, you have to setup the layout yourself. > > People can probably live with that though :) . > > with c++ of course (with the scriptengine this would be abstracted away) > and would permit to even use this just for a little part, like a list > view, mantaining the rest imperative. > > > That's actually a really good idea, since if you want just a QML item you > > probably won't be wanting to write a C++ applet for it. I probably should > > have noticed this since I didn't even use KineticApplet when I wrote my > > C++ applet example (it had to subclass WeatherPopupApplet). The plasma > > items do > > what you would do i this case is just subclass WeatherPopupApplet and add > just > > > need to be given an Applet*, but I suppose that can be passed around. I > > agree that this approach is more powerful. > > oh, i see, plasmoiditem needs to dump properties in the config file... > finiding the parent applet on init is easy, but the config file would get > corrupted if the parent applet changes (that usually doesn't happen) hmm > perhaps it should init to the parent applet configgroup and have a > setconfigGroup() so it could be used also outside Applets?
I don't quite understand what you mean here. I'm not aware of any situation where you would move parts of an applet between applets (change the parent applet). And I also don't understand what you mean by 'used also outside Applets', since the PlasmoidItem is meant to expose Plasma::Applet functionality in QML. Could you give an example? > > We actually have a widget that displays QML already (QmlView). But using > > that in Plasma means using a proxy widget and setting up the plasma > > specific things yourself, which is undesirable. Watch out for a > > PlasmaQmlView in the integration sometime soon. > > yeah, not a proxywidget, the code would just be mostly the kineticapplet > one, just inheriting qgraphicswidget instead of Applet, just to abstract > away the actual qml file loading, it can't be merged with plasmoiditem > since it would have to inherit from 2 qobjects, but perhaps plasmoiditem > can be kept an internal private class > Yep, I've already tried implementing it and it ends up just like that. -- Alan Alpert _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
