[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Guidance in KDE Admin
From:       Luciano Montanaro <mikelima () gmail ! com>
Date:       2008-03-27 10:20:31
Message-ID: 200803271120.31569.mikelima () gmail ! com
[Download RAW message or body]

On Thursday 27 March 2008 11:04:30 Sebastian Kuegler wrote:
>
> Let me explain a bit how I see it.
>
> From measurements we made some time ago, the overhead of running an
> application in PyKDE is about 8MB once for the bindings. CPU-wise, it
> hardly makes any difference since most of the expensive code is still C++.
> I cannot 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
> running ones. So to run a KDE desktop you won't need any Python or Ruby
> bindings, you can live just fine without those apps.
>
> For things like Kcontrol modules, for example, that's not really a problem.
> The advantage of it being easier to write a module for a specific purpose
> outweighs that disadvantages. I don't think this would form a barrier for
> getting some parts of KDE running on your watch -- as long as your watch
> does not need a mountconfig utility ;-)
>
> Which language? Well, I'm a Python guy, but I wouldn't have any problems
> with a Ruby application ending up in one of the KDE modules that get
> typically shipped. Anything free is basically fine with me, although I
> wouldn't like C# to be ending up being that language. Not that its chances
> are particularly high anyway. That doesn't mean that it wouldn't be good to
> have at least one language that is easier to write and deploy supported by
> KDE. The win in terms of development time is tremendous and we can tap into
> a large pool of developers that previously haven't really been able to
> write KDE software. By exercising the bindings in that way, we would make
> sure that the bindings are of high quality as well.

This is not a problem for your typical, current, desktop PC. But many 
linux-friendly devices are being deployed where memory and disk space are 
limited resources (the Classmate, the Eee PC... more models seem on their 
way), so, while I agree that having interpreted code for settings and rarely 
executed programs is a valid choice, I'd rather at least have one "blessed" 
language for this kind of modules.

That may be Python, or something else... I'd prefer one of the ecmascript 
interpreters we ship, actually... 

It would be nice if we had one javascript interpreters instead of two-- soon 
three, but that's another problem.

Luciano
[prev in list] [next in list] [prev in thread] [next in thread]