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