Declarative UI integration v0.2

[Marco Martin]

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?

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

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

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

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

yeah probably it's better not 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.


-- 
Marco Martin