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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
