proposal for full application scripting language in KDE 4
Richard_Dale at tipitina.demon.co.uk
Mon Oct 9 10:23:41 BST 2006
On Monday 09 October 2006 10:07, Guillaume Laurent wrote:
> Richard Dale wrote:
> > Using the results of a survey to optimise the
> > performance of kde4 modules by eliminating language diversity, before
> > anyone has even written apps for them in any dynamic language, is a
> > perfect example of premature optimization in my opinion.
> Richard, if there's one thing I've learned from my time with gtkmm and
> Gnome, it's that language diversity is *NOT* such a good thing. It has
> very strong downsides, the main one being that it needs a whole lot of
> human resources (devs and doc writers) to actually work, which we don't
> have. Otherwise what you end up with is a bunch of half-finished
> bindings which aren't usable in practice because they're not reliable
> and documented enough. The dependency problem is another issue, if you
> want to avoid the chicken/egg problem, the only solution is to have a
> single "official" binding which you know will be installed along with
> KDE. I don't think that trying to have more is doable in practice.
Well I agree that language bindings require a heroic amount of work, and don't
always attract a critical mass of community. I started with Objective-C
bindings which were a complete failure with zero demand. Then I developed
Java bindings which also were largely a failure - I'm still unconvinced that
the Qt Jambi bindings will attract much support within the KDE community. I'd
love to be proved wrong on that though.
Recently, I've been working on Ruby bindings, and am getting some traction. We
have the start of a community that helps each other. QtRuby is getting more
popular because of it is better cross platform than any other binding with
the Qt4 version. Alexander Dymo is working on Ruby support for KDevelop4, and
I will help him once I've done the KDE4 version of Korundum. We will make
sure that we write a suitable app in Ruby, that we can propose for inclusion
in the core kde modules ASAP.
So I agree that we don't want half finished bindings, without a complementary
RAD environment or supporting community. But that doesn't mean we have to
have only one language. I think both the Python and the Ruby bindings for
Qt/KDE are strong enough to qualify. Maybe the Qyoto/Kimono C# bindings won't
reach those high standards, I don't know yet and will see how it turns out.
Note that we are working on C++, Java, C# and Ruby support for KDevelop4. Any
other languages, such as Python can be implemented as plugins in the
extragear module. We haven't included Python, not because we don't like it,
but because there is no suitable developer who has volunteered to implement
equivalent support to the 4 languages we've chosen to target. Of course Eric4
will have good Ruby and Python support, but it isn't a completely native KDE
app, and isn't maintained in the KDE svn.
More information about the kde-core-devel