Using scripting languages for KDE4 main modules

[Boudewijn Rempt]

On Tuesday 03 October 2006 23:10, Alexander Neundorf wrote:
> On Tuesday 03 October 2006 22:53, Michael Pyne wrote:
> > On Tuesday 03 October 2006 16:46, Guillaume Laurent wrote:
> > > On Tuesday 03 October 2006 18:34, Gary L. Greene Jr. wrote:
> > > > Personally, I think this idea of selecting an "official" application
> > > > scripting language is a bad idea, as that again raises the bar for
> > > > new developers.
> > >
> > > See Coolo's message on the matter. Maintaining multiple bindings is not
> > > an option.
> >
> > Sure it is, but I don't think it's an option for an applications that are
> > to be distributed ('blessed') by KDE.
>
> So let the beatings begin !
> Today: Python vs. Ruby
>
> Alex
>
> P.S. seriously, I don't think we can choose one over the other

No... And I think that given the enormous breadth and depth of applications, 
utilities and libraries found in the various kde modules and subprojects, 
it's impossible to impose any arbitrary limitation. Plus, there's a good deal 
of independence. If the majority of koffice developers decides to create 
something we don't have (hard to think of anything...) in Lisp, we'll jolly 
well put it in the koffice distribution. The contingency is extremely remote, 
but it's rather more likely that python, ruby and other languages will appear 
in kde games or education. And it's extremely unlikely that we'll have a 
perl-based replacement for kdm in kdebase.

Maybe it would be enough for apps written in rad languages to get 
an "official" status to create kde-games-ruby, kde-games-python etc (as needs 
arises), modules that will be packaged together with the respective bindings 
(and we have volunteers for pyhon and ruby, right?) and put in the same 
release as the rest of kde.

That way it'll be available for distribution, but the core won't depend on any 
binding being present, so no harm done for those who don't want scripting 
language slowing their desktop down. It's different from the current 
kde-bindings module because apps that use those bindings don't get included 
in a full kde release and so seldom get distributed, and it makes it really 
easy for application developers to get started using something that's just a 
little more productive than C++.

This should work, I think, for apps written in "scripting languages". The 
extension scripting language is another issue, and here I think kross should 
be considered over javascript, no matter what was decided in Malaga at the 
unannounced scripting bof. Not that we should, necessarily, code features in 
python, ruby, perl, javascript, lisp and include them in, say, KMail -- for 
scripts included in the kde (not koffice) release, I'm fine with mandatory 
javascript. But users should have the option to use whatever language they 
know. Programmers don't mind changing languages more often than their 
underwear, but to demand from users that they learn another language just to 
script KMail is, well, too WordPerfect 4.2 for words.
-- 
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/20061003/fcbcafd0/attachment.sig>