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