Declarative UI integration v0.2

Aaron J. Seigo aseigo at kde.org
Fri Oct 2 05:11:47 CEST 2009


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20091001/b20dd189/attachment.sig 


More information about the Plasma-devel mailing list