QML and Plasma -> progress()

Marco Martin notmart at gmail.com
Mon Oct 4 20:41:13 CEST 2010


Hi all,
update on the situation: with a fair amount of hacks now we got the engine and 
the read/write main object as well, that means the js bindings can be stuffed  
in it -almost- seamlessy (i still have to try with extenders, not too 
optimistic on that), so huge win, we can show the value added on top.

so, since now trunk depends from 4.7, a painful merge time is coming, of the 
stuff there is in playground different bits n pieces sould go in different 
places, this is a tentative landscape:

* DeclarativeWidget: it is a qgraphicswidget to make easy the (rather long) 
procedure of loading a qml file that encloses nicely also the 
declaratieengine, maincontext, root object etc.this should go in libplasma, 
alongside the other graphicswidgets, this will be the only public api.

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

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.
but there is  but. of course there won't be all the features from the 
scriptengine available, at the moment it's possible to:
- use plasma widgets and graphicslayouts
- use Plasma::Theme colors
- use dataengines (the way dataengine are used is a bit different to be more 
"declarative") for services to work correctly binding to KConfiggroup would be 
needed (that it's in the scriptengine) so they should be used from c++ in this 
case.
in general, all the complex constructors wouldn't be available from there, i'm 
fine that is a bit limited tough, the one i'm more worried is i18n


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.

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

Cheers,
Marco Martin


More information about the Plasma-devel mailing list