Declarative UI Integration, reprise

Marco Martin notmart at gmail.com
Sat Sep 26 14:01:33 CEST 2009


On Saturday 26 September 2009, Alan Alpert wrote:
> 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
no there isn't and probably never will be a situation where a widget is 
reparented between applets, is just an assumption that wasn't used before
> 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?

well, it doesn't exactly expose the applet functionality, it just gives access 
to the config and the theme, and would be come even more obvious if it will be 
used from the plasmaqmlview class, (where an applet could for instance having 
more than one of them) hmm maybe it should even be called not Plasmoid in qml, 
but something like plasmaqmlitem?

>
> > > 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.
great :)

Cheers,
Marco Martin


More information about the Plasma-devel mailing list