Declarative UI integration v0.2

[Alan Alpert]

On Fri, 2 Oct 2009 18:25:39 Marco Martin wrote:
> 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?

I don't think I explained this clearly, but all QML files have only one root 
element. It's a restriction put into the language due to how the files can 
interact.  So in order to be a valid QML file it will only have one item at the 
top. So what will happen if you have two top level LayoutItems is that you'll 
get a file parse error.

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

That's a good point... I don't seem to be very good at reading the plasma docs 
:)  . SvgWidget does exactly what we want and can be exposed directly. Since 
it has a property that takes an Svg we just expose Svg and FrameSvg as well 
and it should all work.

-- 
Alan Alpert