Hi all,
we just had a little chat here at the mobile sprint about the future
of the mobile gui, that basically means:
* QML
* QtComponents
We already had some kind of a roadmap for a transition of plasma to
qml first then qtcomponents (that in turn enables using scene graph)

the idea is to start porting plasmoids to qml with the binded
qgraphicswidgets as first then starting to write qtcomponents based
widgets after (some play on that has already started by anselmo, artur
and me in playground)
then an homogeneous set of widgets could be used all over kde both on
mobile and desktop apps that would need it.

Now the other part, quite interesting indeed.
We all know the problem about the lack of qscriptengine access from qml..
and even if the access was officially there, there are still missing
things, basically types that are not qobjects, in particular:

* KConfig
* i18n
* K(Q)Icon
* KUrl
* KStandardDirs
* QPixmap (qimages too?)

and possibly other things.. any suggestions? (i would rather add stuff
when needed rather that add everything that comes to mind)

now, this is just stuff from kdecore (and something from Qt itself
that is unfortunately missing) so it should be in that place of the
dependency chain.

so, what is "it": right now the Plasma declarative script engine does
the following things:
- obtains the scriptengine pointer from the declarative engine
- makes the root object read/write
- registers constructors for the mentioned types

would be nice if this is done by a library that can be used by all kde
apps using qml, so the possibilities are:

* as low as it can get: kdecore cons: qdeclarative pulls in linking to
-all- qt modules
* kdeui: would be in a library with other things like qwidgets,
doesn't seem so good (and that lib has too varied stuff already)
* libplasma: the easiest place to implement it is in
Plasma::DeclarativeWidget, but would mean everybody should like to
plasma for that. Now, theming seems something that most of the kde
apps would need (especially in the angle of unified kde wide
qtcomponents) package fallback chain to load different qml file seems
useful as well. However, it would mean linking to libplasma (and
kdeui, and anything else that plasma depends). For the libplasma2
thing could even make sense splitting painting/graphical stuff from
dataengines and what not (without the symbols of the widgets the lib
size should decrease a bit as well)
* last option, the more modular would be doing a little library, in
kdelibs but built as a separate so, that would be either a subclass of
QDeclarativeEngine or a separate object that accesses the engine and
does all the necessary registration.
If an application needs to bind extra stuff not registered from that
class it could still access the engine and do whatever it needs with
it.

Opinions? comments?

Cheers,
Marco Martin
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel