[Kde-pim] using qml from KDE applications

[Volker Krause]

On Saturday 20 November 2010 16:54:17 Marco Martin wrote:
> 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)

That should cover everything we needed for Kontact Mobile IIRC.

The only thing coming to mind when seeing KConfig there is that it would be 
nice if kconfig_compiler would generate Q_PROPERTYs so you could easily 
export KConfigXT classes to QML, but that's entirely unrelated :)

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

Not sure if we already updated our dependency guidlelines for kdelibs as part 
of the platform profile work, but I'd assume something like "don't add any 
new avoidable dependencies", ie. no dependencies that don't have at least 
very good technical reasons for being there (such as needing acces to 
internal API).

> * as low as it can get: kdecore cons: qdeclarative pulls in linking to
> -all- qt modules

see above, as long as we don't need access to internal kdecore API (and afaiu 
we don't) that's IMHO not a good option.

> * kdeui: would be in a library with other things like qwidgets,
> doesn't seem so good (and that lib has too varied stuff already)

probably even worse, given that QtDeclarative pulls in quite a few other Qt 
libs (SQL, Script, XmlPatterns, Network) and thus adds dependencies for kdeui 
users and the other way around forces kdeui on QML users that might not need 
it.

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

much better, since it probably wouldn't add new dependencies to libplasma, but 
still it adds a libplasma dependency to other QML users. In the long run 
that's probably fine, assuming libplasma will contain the "official" KDE 
QtComponents based widget set.

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

From the dependency POV that's the best option IMHO, and the one I would 
prefer personally for now. Would be very easy to use that in Kontact Mobile 
then (and would allow us to drop our own limited implementation), without 
adding extra "weight" (which wouldn't be a big problem on Maemo/MeeGo I 
guess, but it is on WinCE). Additionally, it allows us to work on it now 
already in playground, while kdelibs trunk is still frozen.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-mobile/attachments/20101121/323b9f46/attachment.sig