Declarative UI integration v0.2

[Alan Alpert]

On Fri, 2 Oct 2009 02:33:46 ext Marco Martin wrote:
> On Thursday 01 October 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.
> 
> for the Plasmoid element..
> probably we need a more generic one, like PlasmaQMLWidget (i see you call
>  it LayoutItem, that's fone too), that's unique per qml file.
> in a qml only plasmoid only one PlasmaQmlView will exist and will load a
> single qml file. on a c++ plasmoid could even be more, one qml file per
> widget, so a LayoutItem root per PlasmaQmlView.
> i understand that now you are doing like that. i'm correct?

Not precisely. LayoutItem is an item in the Fx primitives set, which inherits 
QGraphicsLayoutItem. So you don't 'need' one per item, it's just there so that 
it gets laid out. The current design does not have any single item which each 
qml file must have exactly one of - there is no longer anything like the 
plasmoid item. You could have a QGraphicsWidget at the top too, and possibly 
avoid using Fx primitives at all. The only constraint is that, whatever you 
have at the top, if it inherits QGraphicsLayoutItem it'll get laid out 
(otherwise it won't).

> > 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).
> 
> i hope it will be possible to just add properties. what are examples of
> missing ones?
> probably the question is: are all tose properties something we could want
>  in the simple javascript binding too? (because once you add them they'll
>  end up here too)

Upon closer inspection I've noticed there really aren't that many omissions. 
FlashingLabel doesn't seem to have many properties, and ComboBox has no way of 
adding or querying items through properties (unless addItem() is Q_INVOKABLE 
it can't be used). That's all I've noticed so far.

> > 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
> 
> sounds good.
> not sure about finding images, since right now it finds just svgs, would
>  mean it's needed to expose Svg and FrameSvg directly in qml?

I'd like it if I could just expose Plasma::Svg and Plasma::FrameSvg in QML, 
but because they aren't QGraphicsObjects they are hard to use. Plasma::Label 
for example doesn't have a property that takes a Plasma::Svg, so instead we'd 
need to just return the theme-aware path.

Alternately we could write a wrapper item which provides a QGraphicsObject 
shell around the Plasma::Svg. But you can't really write one of those in QML 
like I presume you can in the JS script engine.
 
> > -the DataSource object, as it is in v0.1
> 
> yes
> 
> > -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)
> 
> probably more than a way to ask to display the config dialog 
>  (configRequested signal) is needed a way to inform the qml engine that the
>  config is changed
> 

A slot for that can be added to the Config object.

-- 
Alan Alpert
Software Engineer
Nokia, Qt Development Frameworks