QML and Plasma -> progress()

[Aaron J. Seigo]

On Monday, October 4, 2010, Marco Martin wrote:
> * bindings: register in qml the types for plasma graphicswidgets, theme and
> dataengines. This should be always done asap in the application execution
> and in every plasma shell, so should go in libplasma as well.

is this the code in the bindings/ directory? (not counting bindings/phone, i 
suppose :)

bindings/plasmabindings.h looks rather scary: it includes a bunch of private 
headers, for instance. is this really needed? i see that it is #include'd in 
qmlengine/simplebindings/dataengine.h .. what specifically is needed by the 
qmlengine from that? it would be nice if all that code could be kept 
completely internal to libplasma, wrapped tightly behind the scenes of 
Plasma::DeclarativeWidget.

as for "where", kdeibs/plasma/qml/ is probably sensible?

the bindings look like they'll add ~1200 LOC to libplasma. significant 
addition. if/when QtComponents enters the mix, i think it will be time to step 
back and consider doing a libplasma2 that brings some increased order to the 
collection of our widgets (currently QGraphicsProxyWidgets), QML, things like 
applet configuration, etc.

> Modification i would do compared to the current structure, is to prefix in
> some way the plama widgets (like Plasma.GraphicsWidget.PushButton) to make
> clear is something that i there because is needed now, but qtcomponents
> will be the way to go

agreed

> now, with those two parts would be possible to use qml from c++ plasmoids,
> just load a file in the DeclarativeWidget and that's it.

that is very cool. :)

> now, the scriptengine itself:
> it should go in runtime, even in the same folder of the js one, since atm
> most of the files are basically copies of it, there shouldn't be big
> problems in merging, except  AppletInterface and scriptenv. i hope i'll
> get away with a common superclass or something like that.

some thoughts on that:

* the custom qml package can probably go away and we can add a QML 
subdirectory to the normal Applet package in libplasma.

* we currently don't have a way to easily detect the API type from the 
ScriptEngine; it would be possible to do a sycoca lookup on 
Applet::pluginName() to see what API it is using, though. or mayb even better: 
PlasmoidPackage in libplasma could note this in pathChanged() when setting the 
main script. it already opens up the metadata.desktop file, after all. the 
script engine could work based on the file name of the main script, such as:

const QString mainscript = package()->filePath("mainscript");
if (mainscript.startsWith(package()->filePath("qml")) {
 ... set up the qml stuff ...
} else {
 ... set up the JS stuff ...
}

(in libplasma2, i'd like to re-think how the package metadata is handled; it's 
really awkward atm. one of the bits from the very early days that was never 
critical enough to get too much attention.)

* things like newPlasmaFrameSvg, newPlasmaSvg, etc. (essentially all the 
static methods currently in SimpleJavascriptApplet, with maybe one or two 
exceptions) should probably move into simplebindings/ on their own.

* i18n helpers could perhaps be added to AppletInterface; it'll look a little 
odd but comared to what we're used to (plasmoid.i18n(..) instead of just 
i18n(..)), but it should work in QML then?

after that, aside from features like creating of widgets or animations which 
seem superfluous for QML, it looks like there is a _lot_of overlap between 
these two DataEngines. that's _great_ because it means we should be able to 
get away with a combined implementation.

> So, if it's ok i would like to merge the libplasma part, then start with
> the pain of moving and adapting the pieces of the scriptengine to make one
> that can do both pure js and qml

sounds fun :)

-- 
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: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20101004/b252aca8/attachment.sig