From kde-core-devel Tue Oct 03 21:30:21 2006 From: Boudewijn Rempt Date: Tue, 03 Oct 2006 21:30:21 +0000 To: kde-core-devel Subject: Re: Using scripting languages for KDE4 main modules Message-Id: <200610032330.22447.boud () valdyas ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=115991103411876 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart3291627.7ls1sMrOZx" --nextPart3291627.7ls1sMrOZx Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 n= ot > > > an option. > > > > Sure it is, but I don't think it's an option for an applications that a= re > > 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= ,=20 utilities and libraries found in the various kde modules and subprojects,=20 it's impossible to impose any arbitrary limitation. Plus, there's a good de= al=20 of independence. If the majority of koffice developers decides to create=20 something we don't have (hard to think of anything...) in Lisp, we'll jolly= =20 well put it in the koffice distribution. The contingency is extremely remot= e,=20 but it's rather more likely that python, ruby and other languages will appe= ar=20 in kde games or education. And it's extremely unlikely that we'll have a=20 perl-based replacement for kdm in kdebase. Maybe it would be enough for apps written in rad languages to get=20 an "official" status to create kde-games-ruby, kde-games-python etc (as nee= ds=20 arises), modules that will be packaged together with the respective binding= s=20 (and we have volunteers for pyhon and ruby, right?) and put in the same=20 release as the rest of kde. That way it'll be available for distribution, but the core won't depend on = any=20 binding being present, so no harm done for those who don't want scripting=20 language slowing their desktop down. It's different from the current=20 kde-bindings module because apps that use those bindings don't get included= =20 in a full kde release and so seldom get distributed, and it makes it really= =20 easy for application developers to get started using something that's just = a=20 little more productive than C++. This should work, I think, for apps written in "scripting languages". The=20 extension scripting language is another issue, and here I think kross shoul= d=20 be considered over javascript, no matter what was decided in Malaga at the= =20 unannounced scripting bof. Not that we should, necessarily, code features i= n=20 python, ruby, perl, javascript, lisp and include them in, say, KMail -- for= =20 scripts included in the kde (not koffice) release, I'm fine with mandatory= =20 javascript. But users should have the option to use whatever language they= =20 know. Programmers don't mind changing languages more often than their=20 underwear, but to demand from users that they learn another language just t= o=20 script KMail is, well, too WordPerfect 4.2 for words. =2D-=20 Boudewijn Rempt=20 http://www.valdyas.org/fading/index.cgi --nextPart3291627.7ls1sMrOZx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBFItZudaCcgCmN5d8RAnm/AKDlqsznM88Usza/H3mi847m44fFHACfREyL oN9eNu4DPiotlYKQR8znBeo= =EZV3 -----END PGP SIGNATURE----- --nextPart3291627.7ls1sMrOZx--