KDE 4 (was: [PyKDE] PyQt 4 on openSUSE)

[David Boddie]

On Friday 08 September 2006 21:11:25 +0200, Simon Edwards wrote:
> On Friday 08 September 2006 01:51, David Boddie wrote:

> > Reading through the SIP files for PyKDE, you find lots of information
> > about the way the KDE APIs have evolved over time. If the bindings were
> > too closely tied to some schedule where development was frozen too early
> > before a release,
>
> You mean "too late before release" I assume.

Actually, I meant that if the bindings were frozen along with the rest of
the branch then there may not be enough time to stabilize them, especially
if the core developers are working on their APIs right up to the freeze.

> > there wouldn't be enough time to update the bindings to include
> > changes like these, unless the tools to generate the bindings could
> > manage it automatically. I think a staggered release schedule would work
> > much better.
>
> Releasing PyKDE *after* the main KDE release? We could request from KDE
> release group (is that the name?) that an API freeze be part of the normal
> feature freeze, or part of the string freeze.

I think this would be useful. The bindings don't break the main release, but
the main release can break the bindings. There's no need to freeze too early.

> Or at the very least make a freezing APIs *strongly* recommended.

As long there are no last minute API changes. Sometimes you just can't
recommend something strongly enough. :-/

> For KDE4 I want to see all of the extra dev support stuff that in "PyKDE
> Extensions" [1] rolled into PyKDE, along with support in CMake for building
> Python modules, sip stuff and being able to mix that with regular C++ based
> KDE development.

Tools to make it easier to create bindings for Qt/KDE C++ projects would be
useful, certainly.

> As for IDEs, we already have a very good and capable Python IDE in Eric3.
> Yes, conceptually and marketing wise it would be neater if Eric's
> functionality was also in one do-everything-IDE such as KDevelop. But Eric
> is here already, and I'm not going to complain about it.

There is/was a project to improve cooperation between Python IDEs, but it
appears to have stalled:

  http://pyxides.stani.be/wiki/

In many ways, a really good IDE that understands Python is better than an
IDE that handles lots of different languages. It may be easier to add
plugins or supporting tools for KDE to an IDE that handles Python well than
it is to add Python support to another IDE.

David