QML and Plasma -> progress()

[Marco Martin]

On Monday 04 October 2010, Aaron J. Seigo wrote:
> 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

basically all is needed is 
a) the header being included
b) setupBindings() to be called as soon as possible in the application 
execution. i think it shoul be done in corona, that is the only thing we are 
sure gets created really soon and there is one and only one in

so no, all of this should be private, the scriptengine includes it just 
because it wasn't already done :)



> could be kept completely internal to libplasma, wrapped tightly behind the
> scenes of Plasma::DeclarativeWidget.
> 
> as for "where", kdeibs/plasma/qml/ is probably sensible?

i toght under private, like plasma/private/declarative

> 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

yes, that's not trascurable :/
problem is, bindings are needed from both the scriptengine and plasma-mobile.
what we can do is see if there is something that we can move down to just the 
qml engine (also, the qgraphicslayouts bindings could be renounced? it's a 
wile i don't try qgraphicswidgets with only qml layouts)

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

even breaking libplasma into components could be an idea...
and *if* qtcomponents really becomes the way to go the old widgets becomes 
more an old legacy weight than something else... :/

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

yes, once it's merget it gets easy

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

would be a code copy less

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

yep, it should.
only in the scriptengine tough, still remains the problem of having to i18n in 
a ml file in a c++ plasmoid :/ 

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

yeah, i don't think is  problem having both working.

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


Cheers,
Marco Martin