Declarative UI integration v0.2

[Aaron J. Seigo]

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.

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

Extenders.

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

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

> 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.
 
-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20091001/608c2ab3/attachment-0001.sig