From kde-core-devel  Mon Oct 02 09:29:37 2006
From: Boudewijn Rempt <boud () valdyas ! org>
Date: Mon, 02 Oct 2006 09:29:37 +0000
To: kde-core-devel
Subject: Re: Using scripting languages for KDE4 main modules
Message-Id: <200610021129.39523.boud () valdyas ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=115978140002465
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart1878330.gbBKA13ivE"

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

On Sunday 01 October 2006 17:47, Leo Savernik wrote:

=2E..
> Then we already have three script interpreters+runtimes+bindings hogging=
=20
> memory and drowning performance.=20
=2E..

Yeah, well, you know? I very much doubt the hogging and drowning part. I th=
ink=20
it's pure hyperbole.

> Another hypothetical example (not that far fetched) pretending krita needs
> python and ruby binding to work:
> - kword user doesn't have python and ruby installed.
> - wants to paste image into kword
> - krita flake refuses to load
> =3D> no images in kword documents.

Nope. We're talking plugins here, even the scripting api itself is a Krita=
=20
plugin. The only plugins krita documents depend on are the colorspace=20
plugins. Scripts are for adding functionality, not document features. It ma=
y=20
be conceivable that some writes a filter in Python and uses that filter as =
an=20
adjustment layer, well, in that case that image won't have that effect when=
=20
loaded. But that's a problem for me (and Cyrille, since it's a general=20
OpenRaster issue) to solve.

> The problem of allowing arbitrary (even if restricted to a small number)
> scripting languages leads either to a fast KDE environment that is crippl=
ed
> or a slow, memory eating, fully functional one.

This whole discussion is confused from the start. The big thing about=20
extending applications with scripting is not creating features for=20
distribution: it is making it possible for people to extend the functionali=
ty=20
of their application locally. Like the molecular biologist who scripts kwor=
d=20
and krita to load his research data and create illustrations automatically.=
=20
=46or that use case it _is_ important to offer a variety of language choice=
s=20
because such a domain specialist is not going to learn a new language just=
=20
because the kde gurus tell him so. Same with kicker: if I want to add a qui=
ck=20
script to regularly poll some webservice and display the result on the pane=
l,=20
I would like to do that in the language I'm most proficient with.

KOffice is and will be scriptable in any language for which there's a kross=
=20
plugin. And currently we deliver python and ruby plugins, and work is being=
=20
done on a kjs plugin. And that's a good thing.

And we're talking about application scripting again, instead of writing=20
applications in scripting languages.

> Therefore I suggest that no core component and core application that *is
> needed to make KDE being perceived as fully functional* is written in any
> scripting language except those shipped within KDE (kjsembed), and even
> that one shouldn't be used too liberally.

Looking back the the 3.x times, I see ksjembed having been available all th=
e=20
time and precious little use being made of it. It hasn't enabled easy deskt=
op=20
scripting. It hasn't automatically added scripting to every application.=20
Applications that are kjsembed enabled (kdevelop, are there more?) don't ma=
ke=20
it easy to add scripts. In my view, kjsembed has failed to provide scriptin=
g=20
to KDE. There aren't any applications shipped with kde that are stand-alone=
=20
kjsembed scripts -- or at least, none that I am aware of. I think the=20
use-kjsembed-like-it-or-leave-it approach is flawed.=20

=2D-=20
Boudewijn Rempt=20
http://www.valdyas.org/fading/index.cgi

--nextPart1878330.gbBKA13ivE
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBFINwDdaCcgCmN5d8RAmYsAJ40pQJkmoAI6Og5YRr+hxfulg13gwCfTe+6
6jXh/pQ6GIh8nUfhcm0T26Q=
=CoPd
-----END PGP SIGNATURE-----

--nextPart1878330.gbBKA13ivE--