Using scripting languages for KDE4 main modules

[Richard_Dale at tipitina.demon.co.uk]

On Tuesday 03 October 2006 14:29, Luciano Montanaro wrote:
> On Sunday 01 October 2006 20:40, Stephen Leaf wrote:
> > On Sunday 01 October 2006 7:31 am, Guillaume Laurent wrote:
> > > On Sunday 01 October 2006 13:00, Alexander Neundorf wrote:
> > > > I don't think it would be possible to reach a consensus on this one:
> > > > python <-> ruby <-> java <-> c# ...
> > >
> > > We want a script language, so Java and C# are out of consideration, the
> > > added value compared to C++ just isn't worth it. So it's between Python
> > > and Ruby (at least we all agree that Perl is a no-go :-) ).
> >
> > not everyone, I hate the python syntax. And as for ruby syntax?.. I've
> > seen scribbles that were more readable. Maybe it was just the examples on
> > the official page I dunno but it just churned my stomach.
> > I personally prefer Perl out of those 3 choices.
>
> What is the state of Perl bindings?
There is no work going into the Qt4 version of PerlQt, although it wouln't 
take a huge amount of effort to adapt the Qt4 QtRuby bindings.

> That aside, these languages are attractive in large part because of their
> large libraries, and the problem I see is not using the language on its
> own, but rather the huge dependecies it is likely to require.
>
> Configuration panels are a good example of where scripting languages could
> be used, but do we want half of them written in Python and half in Ruby?
>
> Or could we use javascript instead?
>
> Javascript is not a great language, but we already ship it, is easy enough
> to learn and it's small.
We discussed this at the Malaga aKademy and agreed that Javascript should be 
the scripting language lingua franca of KDE. We also agreed that if 
application developers wanted to add support for other scripting languages 
such as Ruby and Python that was ok too. And that seemed a pragmatic position 
to agree on. If people are complaining that core kde apps shouldn't have Ruby 
or Python dependencies, then just make that part of the build optional - I 
really don't see what the problem is. But having ubiquitous javascript 
scripting and well designed dbus apis is a very important goal, and will not 
add anything much in the way of bloat as far as I can see.

I personally work on *RAD* environments for Ruby (and C#) with bindings and 
kdevelop support, and that is not the same thing as working on *scripting* 
support. I've had trouble following this discussion because some people are 
discussing writing complete apps and whether its ok to include them in the 
kde modules such as kdeedu, others are discussing whether it's ok to include 
complete apps in the core kde modules like kdebase, and still others are 
discussing in process scripting in core/non core apps.

-- Richard