Declarative UI Integration, reprise

[Alan Alpert]

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