From kde-core-devel  Thu Mar 27 10:04:30 2008
From: Sebastian Kuegler <sebas () kde ! org>
Date: Thu, 27 Mar 2008 10:04:30 +0000
To: kde-core-devel
Subject: Re: Guidance in KDE Admin
Message-Id: <200803271104.34905.sebas () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=120661230400786
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart10433874.Q9JMPtErmx"

--nextPart10433874.Q9JMPtErmx
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Thursday 27 March 2008 00:01:38 Sebastian Sauer wrote:
> Nicolas Ternisien wrote:
> > What is your main problem about this Leo ?
>
> I agree with Leo and don't particularly like that idea too. I guess mainly
> cause of two reasons. 1) why Python and not language XYZ and if also
> language XYZ then 2) I hope we don't end to depend on n different
> interpreters to get a basic KDE setup running. Also it may help to keep in
> mind that over the years traditional desktops will be extended/replaced
> with smaller portable devices and there Moore's law isn't that active sin=
ce
> the progress may not go into faster hardware but longer lifetime, smaller
> devices and more functionality (I still hope to see one day the plasma
> analog clock running on my watch).
> I guess my fear is, that we open a door there and wan't be able to provide
> any hint why that door is only open for some (e.g. why exactly Java but n=
ot
> Mono which is GPLv2 too btw? not needed to answer, just a sample that
> matches to what Nicolas wrote and should show that there is already
> potential for conflicts).
> But maybe a general "each language is welcome" and a clear limit to
> optional modules (so, nothing what is needed to have a basic KDE-desktop
> running) would help there already?!

Let me explain a bit how I see it.

=46rom measurements we made some time ago, the overhead of running an=20
application in PyKDE is about 8MB once for the bindings. CPU-wise, it hardl=
y=20
makes any difference since most of the expensive code is still C++. I canno=
t=20
talk about Ruby, but I would guess it's in the same ball park.

Also, I wrote that we don't want to replace core applications, or long runn=
ing=20
ones. So to run a KDE desktop you won't need any Python or Ruby bindings, y=
ou=20
can live just fine without those apps.

=46or things like Kcontrol modules, for example, that's not really a proble=
m.=20
The advantage of it being easier to write a module for a specific purpose=20
outweighs that disadvantages. I don't think this would form a barrier for=20
getting some parts of KDE running on your watch -- as long as your watch do=
es=20
not need a mountconfig utility ;-)

Which language? Well, I'm a Python guy, but I wouldn't have any problems wi=
th=20
a Ruby application ending up in one of the KDE modules that get typically=20
shipped. Anything free is basically fine with me, although I wouldn't like =
C#=20
to be ending up being that language. Not that its chances are particularly=
=20
high anyway. That doesn't mean that it wouldn't be good to have at least on=
e=20
language that is easier to write and deploy supported by KDE. The win in=20
terms of development time is tremendous and we can tap into a large pool of=
=20
developers that previously haven't really been able to write KDE software. =
By=20
exercising the bindings in that way, we would make sure that the bindings a=
re=20
of high quality as well.
=2D-=20
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9=20

--nextPart10433874.Q9JMPtErmx
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUAR+txMmdNh9WRGQ75AQJuOwf+IeLem1ps3dzFKVbMWbP0JEi+xO4WjNto
heF2W4hev/wB0bXgfW5u9fIoxtQugZnKBfO8VrN2ePU+jMj0JLWJH113D9IzM3GS
W/dtJcEY4geRyGxqTXqpx+Qjj9nwFGpwtHBV/b3MoXBWdhp1is4I8+cP2fsAgn3T
Bzi1Ps6Lqw6chZ9Stu9zSDR/052YduJnyOABsQDOzOC8k2xcEcw/igLmfeNNjH+E
iZQ+gSIIh9S/oUArhSJMgQOTD/TSxSwewq4uMM2hOlDs368ZmeT35jCg0jPB74KJ
/0Tycqn6ctaknfPEYUn78JAbSpvC3EC+s1L2yB5XUs2W9kVqeM9D2Q==
=7ruT
-----END PGP SIGNATURE-----

--nextPart10433874.Q9JMPtErmx--