Using scripting languages for KDE4 main modules

[Boudewijn Rempt]

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

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

Yeah, well, you know? I very much doubt the hogging and drowning part. I think 
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
> => no images in kword documents.

Nope. We're talking plugins here, even the scripting api itself is a Krita 
plugin. The only plugins krita documents depend on are the colorspace 
plugins. Scripts are for adding functionality, not document features. It may 
be conceivable that some writes a filter in Python and uses that filter as an 
adjustment layer, well, in that case that image won't have that effect when 
loaded. But that's a problem for me (and Cyrille, since it's a general 
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 crippled
> or a slow, memory eating, fully functional one.

This whole discussion is confused from the start. The big thing about 
extending applications with scripting is not creating features for 
distribution: it is making it possible for people to extend the functionality 
of their application locally. Like the molecular biologist who scripts kword 
and krita to load his research data and create illustrations automatically. 
For that use case it _is_ important to offer a variety of language choices 
because such a domain specialist is not going to learn a new language just 
because the kde gurus tell him so. Same with kicker: if I want to add a quick 
script to regularly poll some webservice and display the result on the panel, 
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 
plugin. And currently we deliver python and ruby plugins, and work is being 
done on a kjs plugin. And that's a good thing.

And we're talking about application scripting again, instead of writing 
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 the 
time and precious little use being made of it. It hasn't enabled easy desktop 
scripting. It hasn't automatically added scripting to every application. 
Applications that are kjsembed enabled (kdevelop, are there more?) don't make 
it easy to add scripts. In my view, kjsembed has failed to provide scripting 
to KDE. There aren't any applications shipped with kde that are stand-alone 
kjsembed scripts -- or at least, none that I am aware of. I think the 
use-kjsembed-like-it-or-leave-it approach is flawed. 

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20061002/f89b2246/attachment.sig>