On October 1, 2009, Alan Alpert wrote: > On Fri, 2 Oct 2009 02:33:52 ext Aaron J. Seigo wrote: > > On October 1, 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. > > > > > > 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 > > > > there will also be the stock Plasma animations; internally the use > > QtKinetic but they are "prebuilt" ones that can be requested by name. > > I don't think we can just drop them in directly, the QML animations are a > bit different to straight Kinetic ones (due to being used slightly > differently). But if the plasma ones are just presets then it should be > easy to create QML animations with the same name and effect. QML > animations use Qt Kinetic's animation framework internally too, so there > should be no visual difference. I will take a better look at seeing if > they could be used directly though, before copying them.
that sounds sub-optimal. if QML uses Kinetic internally, then why can't it incorporate other Kinetic based animations? > > Services are also important in addition to the DataEngines, so that we > > can have two way communication there. > > I don't know the services very well, but it looks like they too can be > directly exposed. yes > I've given up on making services declarative rather quickly though :), do > tell me if I've overlooked it too hastily and they could be controlled > with properties in a declarative fashion. no, i don't think so. > > one thing to remember bout config is that there is both config local to > > an instance of the widget (e.g. Berlin) and config shared beetween all > > instances of that widget (e.g. "use metric") ... a detail, though :) > > Sounds like an important detail one. Wouldn't be too hard to replace > 'persistent' with 'local' and 'global' objects though; that's probably a > good improvement. cool... > > > 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'. > > > > we've done the same thing with other script engines and it seems a good > > approach. > > I assume you mean that you have NOT exposed the applet directly in the > other script engines (even the JS one). correct. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
