Declarative UI integration v0.2

[Alan Alpert]

On Fri, 2 Oct 2009 02:33:52 ext Aaron J. Seigo wrote:
> On October 1, 2009, Alan Alpert wrote:
> > Hi Plasma Devs,
> >
> > The feedback on this list was of great help in rethinking the design of
> > the Qt Declarative plasma integration. I thought I might spend more time
> > thinking about the design and soliciting feedback before I rush off and
> > implement something this time :).
> >
> > The way we get a QML file loaded into an applet is with a PlasmaQmlView,
> > a QGraphicsWidget that you can give a QML file and then deal with like
> > any other QGraphicsWidget. One reason we need the redesign is that you
> > should be able to have multiple ones in an Applet and the 'Plasmoid' item
> > was supposed to only be used once. The PlasmaQmlView automatically loads
> > the Plasma items library from the C++ side, so that you can import it in
> > QML. There would also still be the script engine for QML only applets.
> >
> > Once the file is loaded we need to provide ways for it to access plasma
> >  specific functionality. The plasma functionality which I believe needs
> > to be exposed is:
> > -Plasma Widgets
> > -Plasma Theme (SVGs/colors)
> > -Plasma data sources (through data engines)
> > -Centrally managed configuration data storage
> > -Config dialog requested
> 
> there will also be the stock Plasma animations; internally the use
>  QtKinetic but they are "prebuilt" ones that can be requested by name.

I don't think we can just drop them in directly, the QML animations are a bit 
different to straight Kinetic ones (due to being used slightly differently). But 
if the plasma ones are just presets then it should be easy to create QML 
animations with the same name and effect. QML animations use Qt Kinetic's 
animation framework internally too, so there should be no visual difference. I 
will take a better look at seeing if they could be used directly though, 
before copying them.

> Services are also important in addition to the DataEngines, so that we can
> have two way communication there.

I don't know the services very well, but it looks like they too can be 
directly exposed. As QObjects they can be created in QML just fine and then you 
should be able to use the same JS to control them as the plasma JS bindings, 
including signal connections.

I've given up on making services declarative rather quickly though :), do tell 
me if I've overlooked it too hastily and they could be controlled with 
properties in a declarative fashion.

> Extenders.

I'll have to test this but I think they can actually be exported the same as 
the Plasma Widgets. Since they can be controlled through properties already I 
see no reason why we can't have 
Extender{
	id: extenderItem
}
ExtenderItem{
	extender: extenderItem
}

Although the object hierarchy might get a little confusing, since it sets the 
parentItem to the extender when that property is set.

> for the script engine based stuff, access to resources (svg's, data files,
> etc) via the package()

Should be easy enough to add a package object in the Plasma namespace, and 
only for the script engine. However in QML we have all paths interpreted 
relative to the mail QML file. Since that's in the package structure, all 
relative paths will find the right thing no matter where it's installed, since 
(I think) the entire package structure is installed as is.

> i think that should be about it.
> 
> > Plasma Widgets are exposed directly - you can just go Plasma.PushButton
> > for example and it's there. For the moment this works fine, but because
> > they weren't designed for QML use their property interfaces are not
> > always that great. To fix this I think we'd either write wrappers (which
> > can be done now) or add more properties to the Plasma Widgets (which
> > would be done when/if this leaves the playground).
> 
> adding properties sounds the sanest and likely the least amount of work to
>  me.
> 
> > My current thought for the remaining points (Theme, Data sources, Config
> >  stuff) is to have a new QML item created for each, providing a QML
> >  interface to that functionality. These would be
> > -a Theme global object in the Plasma QML namespace, with functions to get
> > colors or find images/resources
> > -the DataSource object, as it is in v0.1
> > -A Config global object, with a configRequested signal and a 'persistent'
> >  object you can set properties on (e.g.
> >  Plasma.Config.persistent.weatherLocation = "Berlin" would store
> >  weatherLocation=Berlin in the right place in the appletsrc file)
> 
> one thing to remember bout config is that there is both config local to an
> instance of the widget (e.g. Berlin) and config shared beetween all
>  instances of that widget (e.g. "use metric") ... a detail, though :)
> 
Sounds like an important detail one. Wouldn't be too hard to replace 
'persistent' with 'local' and 'global' objects though; that's probably a good 
improvement.

> > We currently expose the Plasma::Applet* directly though, as the 'applet'
> > global variable, and I'm not sure if this is good design (exposing too
> > much internals). So currently I don't actually mention that and advise
> > that it not be used, but if it were to be used then maybe you could
> > access the theming functions directly. That would remove the need for the
> > QML Theme object but I'm currently leaning away from making the applet
> > variable 'public'.
> 
> we've done the same thing with other script engines and it seems a good
> approach.
> 
I assume you mean that you have NOT exposed the applet directly in the other 
script engines (even the JS one). If so then I'll stick with that approach.

-- 
Alan Alpert
Software Engineer
Nokia, Qt Development Frameworks