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
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
