>> If an application exists, is well written
>> and respect the criteria defined previously by Allen, why not adding
>> it ? It's not Cobol, nor C#, but a modern and clean object oriented
>> scripting language.
> 
> I already stated my reasons, I don't think I should repeat them.

Just want to support Andras here, so that people do not get the 
impression that he is alone in this. I fully agree that for now, a 
basic, minimal KDE desktop should not depend on python or other 
scripting language, specially for daemons or system components in kdebase.
Why?
It has nothing to do with how easy it is to create the app, at least for 
me. C++ using Qt/KDE is frankly almost a scripting/macro language these 
days. But I digress: the problem is that in order to save (and this is 
questionable) some hours of development time for ONE developer which has 
a personal preference, we end up requiring MILLIONS of computers to 
spend additional cpu cycles, and require additional memory/resources. 
And I am not sure we make contribution easier: it could very well be the 
opposite, as most developers do not know both languages, and will not be 
able to help fixing/debugging them. We might even create a small rift in 
the community, instead of expanding it.
The resource wasting part specially is not responsible imo. And we open 
the door for each developer writing a basic control panel module in a 
different scripting language, which is nuts imo for an integrated 
desktop environment. IMO we should try to cut dependancies for the basic 
desktop libraries and components, not add to them.
But, I think we need to experiment instead of just discuss these issues. 
So here comes the diplomatic part of this email.
I propose we study the potential impact of these changes using the 
following policy: for stand alone applications, games, plasmoids, 
anything else, we should strongly encourage the use of bindings and 
Python/JavaScript/Ruby anything else. We could maybe start with 
peripheral packages like our kdegames, and figure it out the issues (if 
any) with bindings, packaging, etc. We will be able to figure it out if 
there are impacts on the community aspect, and iron out the problems 
brought out in kcd with KDE-ification of these applications, as a first 
step. Who knows, maybe I am all wrong and it will open up the doors for 
an influx of new developers, plasmoids, apps, tools. And the community 
would double or triple, and no one will mind about additional 
dependencies. When/if this happens, we extend this policy to libs/base, 
with data to back it up, and no great harm done if it does not work. But 
for now, as we have not tried this, I am against encouraging resource 
wasting for a basic part of the system that has to run and be installed 
by default.

Regards,
Mauricio Piacentini
_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team