Declarative UI integration v0.2

[Marco Martin]

On Friday 02 October 2009, Alan Alpert wrote:
> 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).

ok. so what happens if you have a qmlfile with two LayoutItem at top level? 
both get inserted into the layout?

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

yeah, making addItem() Q_INVOKABLE seems to make sense, otherwise the widget 
is not very useful also in javascript :)

> > > 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.
well, SvgWidget is basically that.

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


-- 
Marco Martin