--===============1340700144==
Content-Type: multipart/signed;
  boundary="nextPart75917040.5I8hjnMV57";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart75917040.5I8hjnMV57
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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=
=20
nice if kconfig_compiler would generate Q_PROPERTYs so you could easily=20
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 pa=
rt=20
of the platform profile work, but I'd assume something like "don't add any=
=20
new avoidable dependencies", ie. no dependencies that don't have at least=20
very good technical reasons for being there (such as needing acces to=20
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 afa=
iu=20
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=
=20
libs (SQL, Script, XmlPatterns, Network) and thus adds dependencies for kde=
ui=20
users and the other way around forces kdeui on QML users that might not nee=
d=20
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=20
still it adds a libplasma dependency to other QML users. In the long run=20
that's probably fine, assuming libplasma will contain the "official" KDE=20
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.

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

regards
Volker

--nextPart75917040.5I8hjnMV57
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)

iD8DBQBM6OUxf5bM1k0S0kcRAllQAKCHlQraYApKNlVV9taRvjUAS04+DgCdF/bi
fQIE6STkIrF29RfDdA2wUxo=
=f3Sr
-----END PGP SIGNATURE-----

--nextPart75917040.5I8hjnMV57--


--===============1340700144==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Kde-mobile mailing list
Kde-mobile@kde.org
https://mail.kde.org/mailman/listinfo/kde-mobile

--===============1340700144==--