Using scripting languages for KDE4 main modules
boud at valdyas.org
Mon Oct 2 10:29:37 BST 2006
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: not available
More information about the kde-core-devel