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