Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
Hi, The short answer is that I'd like to not see such apps in the main modules. With main I mean something that you must build and install to have a usable KDE. On Thursday 27 March 2008, Allen Winter wrote: Do we allow Python/Ruby/C#/Perl etc. apps in the KDE main modules? If so, which ones and why? I think kdelibs is out of question. :) For the language 1) must have a mature, working, kde binding (i.e. there isn't a working perl binding IIRC) Here is one of the main problems: those apps will work only if you have their bindings installed. But the bindings need to be generated whenever something changes in the libraries, so you might end up with a none- working app in a main module because the bindings were not yet updated. My other concern is speed and memory usage. If we start to have a mix of different scripting applications that you have to run in order to have a usable KDE... I have no problems having extensions or even full apps in those languages as long as I am not forced to run them. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
Here is one of the main problems: those apps will work only if you have their bindings installed. But the bindings need to be generated whenever something changes in the libraries, so you might end up with a none- working app in a main module because the bindings were not yet updated. My other concern is speed and memory usage. If we start to have a mix of different scripting applications that you have to run in order to have a usable KDE... I have no problems having extensions or even full apps in those languages as long as I am not forced to run them. Andras -- Why will your Python app will use something new in the KDE API before having the binding ready and updated ? Moreover, changes in the KDE API will only massively be done for major version (KDE 4 -5), and in this case, all KDE source code will be broken at once. About the memory usage, we are currently talking about integrating *Python* scripting language only, not a mix of different scripting applications. I must admit that I was sceptical the first time I heard guidance was in Python, but in any machine I used it, it always start fast. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Friday 28 March 2008, Nicolas Ternisien wrote: Why will your Python app will use something new in the KDE API before having the binding ready and updated ? Moreover, changes in the KDE API will only massively be done for major version (KDE 4 -5), and in this case, all KDE source code will be broken at once. I never worked with the bindings, but are you sure they always work and will never break on minor releases? Or that they will be ready at the same time when a new KDE version comes out? IIRC there were many times problems with the kdebindings module in KDE3. About the memory usage, we are currently talking about integrating *Python* scripting language only, not a mix of different scripting applications. I must admit that I was sceptical the first time I heard guidance was in Python, but in any machine I used it, it always start fast. I'm pretty sure it works fast on my desktop machine as well, but what about my laptop with 192MB RAM? Yes, it is outdated, but perfectly usable for daily, none developing work. If we allow Python apps, we will have to allow other apps as well. If I can't get a usable desktop without those apps, I will end up with a bloated system. Guidance is a border case, because on most systems you can work without it as well, with the distribution provided tools. But eg. a system settings module (like desktop configuration or such), a mail client, or even the default calculator should work without external dependencies. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On 28.03.08 09:41:28, Nicolas Ternisien wrote: Here is one of the main problems: those apps will work only if you have their bindings installed. But the bindings need to be generated whenever something changes in the libraries, so you might end up with a none- working app in a main module because the bindings were not yet updated. My other concern is speed and memory usage. If we start to have a mix of different scripting applications that you have to run in order to have a usable KDE... I have no problems having extensions or even full apps in those languages as long as I am not forced to run them. Why will your Python app will use something new in the KDE API before having the binding ready and updated ? Moreover, changes in the KDE API will only massively be done for major version (KDE 4 -5), and in this case, all KDE source code will be broken at once. Did you follow PyKDE3 releases? Its always been lagging behind KDE3.x changes quite a bit due to time constraints at the authors side. And its not just the big changes of major versions that need changes in the bindings, there's plenty of API that gets added between minor releases. Thats one of the reasons why PyQt bindings are only provided for rc's and releases (and sometimes beta's) of Qt. About the memory usage, we are currently talking about integrating *Python* scripting language only, not a mix of different scripting applications. As soon as you allow one scripting language in a main KDE module you'll basically have to allow all or try to fight all those naggers that file thousands of reports asking for their preferred language. I must admit that I was sceptical the first time I heard guidance was in Python, but in any machine I used it, it always start fast. Thats also what I've seen, except a few performance problems with model/view classes in erci4 - though that was more than 6 months ago. Andreas -- You will be a winner today. Pick a fight with a four-year-old. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Friday 28 March 2008, Andreas Pakulat wrote: On 28.03.08 09:41:28, Nicolas Ternisien wrote: Why will your Python app will use something new in the KDE API before having the binding ready and updated ? Moreover, changes in the KDE API will only massively be done for major version (KDE 4 -5), and in this case, all KDE source code will be broken at once. Did you follow PyKDE3 releases? Its always been lagging behind KDE3.x changes quite a bit due to time constraints at the authors side. And its not just the big changes of major versions that need changes in the bindings, there's plenty of API that gets added between minor releases. Thats one of the reasons why PyQt bindings are only provided for rc's and releases (and sometimes beta's) of Qt. the, to me anyways, obvious answer here is that python/ruby apps would simply not have access to all the same api the C++ apps would at the same time. no big deal, really the manpower issue is a real one, though, and it's one we only encourage by various acts of _discouraging_ their use. developer base is calculated as a fraction of the user base, after all ... so we have a kind of chicken-and-egg problem that we could solve pretty easily. and yes, i think the solution is easy because the bindings have a long track record now and apps built on them have shown that it does work very well in practice. About the memory usage, we are currently talking about integrating *Python* scripting language only, not a mix of different scripting applications. As soon as you allow one scripting language in a main KDE module you'll basically have to allow all or try to fight all those naggers that file thousands of reports asking for their preferred language. i think we can probably say these languages are ok.. and stick with it. the choices are probably pretty obvious, based on common sense things like: * primary support (runtimes, etc) being Free software * quality KDE bindings having been available and continuing to be available -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Trolltech signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Friday 28 March 2008, Andras Mantia wrote: On Friday 28 March 2008, Nicolas Ternisien wrote: Why will your Python app will use something new in the KDE API before having the binding ready and updated ? Moreover, changes in the KDE API will only massively be done for major version (KDE 4 -5), and in this case, all KDE source code will be broken at once. I never worked with the bindings, but are you sure they always work and will never break on minor releases? Or that they will be ready at the same time when a new KDE version comes out? IIRC there were many times problems with the kdebindings module in KDE3. Well there were many problems with kdebindings because there were two few applications using them, which means too few applications testing the bindings. So sure there are regressions that happen, but, it also happen in kdelibs, or other C++ applications, the best way to find those regression is to have widely use applications using those bindings. And, for the record, python-qt3/kde3 wasn't distributed in kdebindings3 ;) About the memory usage, we are currently talking about integrating *Python* scripting language only, not a mix of different scripting applications. I must admit that I was sceptical the first time I heard guidance was in Python, but in any machine I used it, it always start fast. If we allow Python apps, we will have to allow other apps as well. If I can't get a usable desktop without those apps, I will end up with a bloated system. Guidance is a border case, because on most systems you can work without it as well, with the distribution provided tools. But eg. a system settings module (like desktop configuration or such), a mail client, or even the default calculator should work without external dependencies. Since it's script-based application, once dependencies (kdebindings) is installed, isn't it easy for the user to install them if he wants to use them ? For me that would be the great force of those languages. There is of course the security issue, but maybe we can use gpg signing of those applications with an easy UI to check ? (like on windows ;) ) -- Cyrille Berger ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
Why will your Python app will use something new in the KDE API before having the binding ready and updated ? Moreover, changes in the KDE API will only massively be done for major version (KDE 4 -5), and in this case, all KDE source code will be broken at once. Did you follow PyKDE3 releases? Its always been lagging behind KDE3.x changes quite a bit due to time constraints at the authors side. And its not just the big changes of major versions that need changes in the bindings, there's plenty of API that gets added between minor releases. Thats one of the reasons why PyQt bindings are only provided for rc's and releases (and sometimes beta's) of Qt. About the memory usage, we are currently talking about integrating *Python* scripting language only, not a mix of different scripting applications. As soon as you allow one scripting language in a main KDE module you'll basically have to allow all or try to fight all those naggers that file thousands of reports asking for their preferred language. I must admit that I was sceptical the first time I heard guidance was in Python, but in any machine I used it, it always start fast. Thats also what I've seen, except a few performance problems with model/view classes in erci4 - though that was more than 6 months ago. Andreas -- IMHO, it's just because no main KDE core applications uses those bindings that explains they always have some problems and are often delayed compared to current KDE API. When motivated developers will ask why the X function is not available in bindings, or why it is broken, be sure the current problems you have with binding will be fixed. And moreover, maybe those developers will also help fixing the bindings too. As Aaron said, a Python KDE apps will have some late compared to KDE C++ apps, but why not ? Is it so important ? About other scripting languages, as often seen in Open Source, it's people who code who generally decide about future improvements and choices (we already saw this when CMake replaces first choice Scons because of better support). So Python is the first in the scripting language list because Guidance exists, and because it's a cool apps suite. Other scripting languages will be accepted only because something useful for KDE exists, not just because some gurus come here to request the adding of their favorite language. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Friday 28 March 2008, Andreas Pakulat wrote: As soon as you allow one scripting language in a main KDE module you'll basically have to allow all or try to fight all those naggers that file thousands of reports asking for their preferred language. BTW, will it be strange when I will ask to include kommander executor in kdebase? ;) Of course I will oppose to use Kommander for core apps just like I don't like to have core apps written in other scripting languages. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
Updated Policy, based on 1-day's worth of discussion: For the language 1) must be an open, free language that meets our licensing requirements 2) must be a mature, high quality language with a large, vibrant support community and a long expected lifespan. 3) must have mature, high quality KDE bindings available 4) must be mature and operational on all our target platforms 5) must be able to provide full translations and internationalizations For the app: 1) must perform: speed-wise and memory-wise 2) must follow the kde look-and-feel, widgets, etc 3) must follow all our rules (docbook, fully i18n and i10n, Krazy ...) 4) not permitted in kdelibs or kdepimlibs As is our tradition, the module coordinator, release team, and the KDE project as a whole will make the final decision about which languages and apps are appropriate. Comments? ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
Really clean and interesting policy. Will it be added to Techbase after comments ? On Fri, Mar 28, 2008 at 2:23 PM, Allen Winter [EMAIL PROTECTED] wrote: Updated Policy, based on 1-day's worth of discussion: For the language 1) must be an open, free language that meets our licensing requirements 2) must be a mature, high quality language with a large, vibrant support community and a long expected lifespan. 3) must have mature, high quality KDE bindings available 4) must be mature and operational on all our target platforms 5) must be able to provide full translations and internationalizations For the app: 1) must perform: speed-wise and memory-wise 2) must follow the kde look-and-feel, widgets, etc 3) must follow all our rules (docbook, fully i18n and i10n, Krazy ...) 4) not permitted in kdelibs or kdepimlibs As is our tradition, the module coordinator, release team, and the KDE project as a whole will make the final decision about which languages and apps are appropriate. Comments? ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Friday 28 March 2008, Allen Winter wrote: 1) must perform: speed-wise and memory-wise I'd like to add here that those apps should not be resident apps (apps that need to run continuously). I'm not saying that such applications cannot be written in scripting languages, but they should not be installed and run by default. This means that kdebase is probably another module that should not accept script applications. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
Le Friday 28 March 2008 03:21:56 pm Andras Mantia, vous avez écrit : I'd like to add here that those apps should not be resident apps (apps that need to run continuously). I'm not saying that such applications cannot be written in scripting languages, but they should not be installed and run by default. This means that kdebase is probably another module that should not accept script applications. Andras So you rule out the printing-applet which is in kdereview and intended to move to kdebase? Anne-Marie ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
Andras Mantia wrote: On Friday 28 March 2008, Allen Winter wrote: 1) must perform: speed-wise and memory-wise I'd like to add here that those apps should not be resident apps (apps that need to run continuously) rationale being? (because this seems to target system-config-printer-applet that jriddell's been working on, which I'd really really like to see). -- Rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Friday 28 March 2008, Allen Winter wrote: That would eliminate Jonathan's print config tool from consideration. Do you really mean kdebase-runtime? I know, and this is what I meant. Of course IMO. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Friday 28 March 2008, Rex Dieter wrote: rationale being? (because this seems to target system-config-printer-applet that jriddell's been working on, which I'd really really like to see). The rationale is that the interpreter executable needs to be permanently in the memory. And if we allow it, and allow similar tools running another interpreter, we will end up with a much higher memory usage. Andras PS: I will test this and guidance once my KDE trunk checkout finished compiling. -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Friday 28 March 2008, Allen Winter wrote: Comments? 1) Brilliantly said 2) ... 3) Profit -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Trolltech signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Friday 28 March 2008, Allen Winter wrote: On Friday 28 March 2008 10:21:56 Andras Mantia wrote: On Friday 28 March 2008, Allen Winter wrote: 1) must perform: speed-wise and memory-wise I'd like to add here that those apps should not be resident apps (apps that need to run continuously). I'm not saying that such applications cannot be written in scripting languages, but they should not be installed and run by default. This means that kdebase is probably another module that should not accept script applications. That would eliminate Jonathan's print config tool from consideration. Do you really mean kdebase-runtime? there's probably also value to having long lived workspace apps written in compiled languages (they all are right now) as well ... so there are probably some kdebase-workspace considerations (that said, plasma will use scripting for add-ons more and more) i don't think, however, that a print configuration matters one whit as to which language (of the ones that meet the criterion you laid out) it is implemented in -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Trolltech signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Friday 28 March 2008, Andras Mantia wrote: PS: I will test this and guidance once my KDE trunk checkout finished compiling. And I failed. printer-applet has some dependencies (python-cups, hal- cups-utils) that I couldn't find for my distribution (opensuse). This is already a problem. So I read the k-c-d thread and the README file and it became clear that the app should be in playground and not kdereview: - it is not using the KDE libraries, but the Qt ones. Others were complaining it does not look like the rest of KDE. This also shows the issue with the bindings, because the reason invoked was a bug in the bindings (or wrong interaction between PyKDE and python-dbus) - it uses a different translation method - it wants to install in /usr/share/..., instead of respecting the KDE install dir Guidance is not ported to KDE4 so here there is nothing to test. My opinion did not change, but more, I believe even more that core apps need to be C++. Those can also be fixed my most of the KDE developers. :) Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Fri, Mar 28, 2008 at 05:43:23PM +0200, Andras Mantia wrote:
On Friday 28 March 2008, Andras Mantia wrote:
PS: I will test this and guidance once my KDE trunk checkout finished
compiling.
And I failed. printer-applet has some dependencies (python-cups, hal-
cups-utils) that I couldn't find for my distribution (opensuse). This is
already a problem. So I read the k-c-d thread and the README file and it
became clear that the app should be in playground and not kdereview:
- it is not using the KDE libraries, but the Qt ones. Others were
complaining it does not look like the rest of KDE. This also shows the
issue with the bindings, because the reason invoked was a bug in the
bindings (or wrong interaction between PyKDE and python-dbus)
Trolltech says the issue causing this should be fixed in Qt 4.4 RC1.
- it uses a different translation method
It uses gettext, same as kdelibs. See above for the kdelibs issue.
- it wants to install in /usr/share/..., instead of respecting the KDE
install dir
It installs to ${DATA_INSTALL_DIR}.
My opinion did not change, but more, I believe even more that core apps
need to be C++.
That attitude will mean we have less programmers and less programmes.
Jonathan
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Friday 28 March 2008, Jonathan Riddell wrote:
bindings (or wrong interaction between PyKDE and python-dbus)
Trolltech says the issue causing this should be fixed in Qt 4.4 RC1.
That's good news.
- it uses a different translation method
It uses gettext, same as kdelibs. See above for the kdelibs issue.
As I said, I couldn't test, I relied on what was said on k-c-d (see the
post from Chusslove Illich).
- it wants to install in /usr/share/..., instead of respecting the
KDE install dir
It installs to ${DATA_INSTALL_DIR}.
That was written in the README file:
hal-cups-utils and system-config-printer like to install to
/usr/share/system-config-printer, if you put it elsewhere change the
SYSTEM_CONFIG_PRINTER_DIR variable in printer-applet.py
So I believed it. Or...is system-config-printer another dependency?
Because in that case It is a Qt port of system-config-printer by Tim
Waugh from Red Hat. is misleading.
My opinion did not change, but more, I believe even more that core
apps need to be C++.
That attitude will mean we have less programmers and less programmes.
I doubt refusing such apps in core modules will have this effect.
Andras
--
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
signature.asc
Description: This is a digitally signed message part.
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Friday 28 March 2008, Andras Mantia wrote: On Friday 28 March 2008, Andras Mantia wrote: PS: I will test this and guidance once my KDE trunk checkout finished compiling. And I failed. printer-applet has some dependencies (python-cups, hal- cups-utils) that I couldn't find for my distribution (opensuse). This is already a problem. it's no more or less a problem than any other dependencies. and we have quite a list of them. let's try to stay focussed on the real issue, scripting, rather than writing a laundry list of things that are neither here nor there when it comes to scripting. My opinion did not change, but more, I believe even more that core apps need to be C++. like all bugs, these get fixed if there is sufficient manpower and reason to apply to it. by keeping everything c++ we may as well just decide to not use scripting languages at all, ever because the level of quality and support will always be pathetic. in fact, one might say that the current state of affairs is due exactly to the position you are taking right now. as i said before, this is a chicken and egg problem ... if we simply take a little bit of pain right now, we stand a chance for things to improve dramatically with time. and seeing the state of the printer app this would be replacing (e.g. none; it's non-existent in kde4 right now), i think having something that exists totally trumps a theoretical c++ app that doesn't. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Trolltech signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
Sure, but this also exposed the problem that having a Python app makes our lives not easier than I would expected, but in some ways even harder. In the particular case it has dependencies not available in a modern and widely used distribution and for some of them it is suggested to get from svn. Yes, and where did you find your binary Qt 4.4 version to compile KDE 4 ? You compile it too from SVN. as Aaron said, this is because something is not widely used that it is not available everywhere. How many CMake version every distributions packaged before KDE 4 decided to make it its builder ? There is a lot of things that could be implemented in such languages and I would not oppose to them. So I cannot believe that such an attitude scared away the developers. After all there was Guidance for KDE3, it was accepted in KDE extragear, just like K3B, KTorrent or KMPlayer was. And we can do the same now. Again, I just don't like the idea to have applications that are a must on a KDE desktop to be written in scripting languages. If they are daemon like ones, that's even worse. If there is a very good Plasma applet written in Python that I like, I may decide to use it, just don't make e.g. the clock a Python application. Or Ruby. And why not ? It is as if you think there is an unlimited pool of available developers, all with perfect skills in C++. Developers who contributes to KDE come with their skills, and you seem to close the KDE door to Python-only developer who would like to create a Clock in Python for the KDE desktop ? He has to know C++ only to contribute to KDE ? This kind of languages and the way and problems to integrate them well in KDE are the necessary brick to open more the development process to other people. and seeing the state of the printer app this would be replacing (e.g. none; it's non-existent in kde4 right now), i think having something that exists totally trumps a theoretical c++ app that doesn't. It is unfortunate that in this case there is no c++ app replacing it. Sincerely I was not aware of it. I'd rather ask for public help to either port kjobviewer to KDE4 or write a new one. Can even be a SoC project. Once again, it's as if Google will always give money to KDE project for re-implement something. 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. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
