Using scripting languages for KDE4 main modules
l.savernik at aon.at
Sun Oct 1 16:47:09 BST 2006
Am Sonntag, 1. Oktober 2006 13:07 schrieb Boudewijn Rempt:
> > For the latter case, there's no decision on official language, since
> > there doesn't have to be. Applications can be written using any binding.
> > But, as this thread has proven, the basic applications must be in C++ so
> > that memory consumption stays low.
> I haven't seen "proof", just some assertions, but aside from that, hadn't
> we better define a list of "the basic applications" then -- Leo's list is
> obviously much too large. If the list of basic applications for which C++
> is required, then people who prefer a little more efficiency in their
> development process know what's left for them.
My list is purportedly encompassing to prevent this:
- A writes support for new important formula for kspread in ruby
- B writes new important dialog for kspread in python
- C writes new important other functionality for kspread in fooblargh
(where "new important" means functionality already contained in excel whose
support is considered crucial to be perceived as a "full blown" app)
Then we already have three script interpreters+runtimes+bindings hogging
memory and drowning performance. The user now has two choices: Doing without
scripting languages, leading to bug report "kspread doesn't support 'foo'",
or going through the hassle of setting up all the dependencies, leading to
bug report "kspread is ten times as slow as and incurs tenfold memory usage
compared to excel doing 'foo'".
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.
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.
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.
I absolutely don't care about external extensions that are not released within
the basic KDE distribution. They may depend on whatever scripting language
More information about the kde-core-devel