Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)

Nicolas Ternisien nicolas.ternisien at gmail.com
Fri Mar 28 10:40:39 CET 2008


>
> > 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.


More information about the release-team mailing list