Declarative UI integration v0.2

[Alan Alpert]

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
Please correct me if anything is missing from this list or is incorrect.

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

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)

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'. 

The 'Plasmoid' item from v0.1 would disappear completely. If your root item is 
a QGraphicsLayoutItem subclass you'll be installed in a QGraphicsLayout 
automatically, otherwise you can watch the size property of the 'applet' 
global variable if you want (which IS the whole applet, not just the QML 
part).  I'm unsure as to whether this is the best idea(but I haven't thought 
of anything better), as in the script engine you might want the additional 
structure of having a Plasmoid item as the root, and in that case it is the 
single item representing the Plasmoid.

So far I have just implemented removing the Plasmoid item, to make sure that 
they can still work like that. Note that QML tries to solve version 
compatibility problems by having the version in the import statement, so while 
Plasma 0.2 has no Plasmoid item, Plasma 0.1 has it (and all the other items) 
just as it was and so all the examples still work as is.

I would appreciate any feedback you have on this design, remembering that Qt 
Declarative itself is still in development and so feedback on how it works can 
still be acted upon.

-- 
Alan Alpert (aalpert on irc)
Software Engineer
Nokia, Qt Development Frameworks