Declarative UI Integration, reprise

[Marco Martin]

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?

> 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

-- 
Marco Martin