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 _______________________________________________ PyKDE mailing list PyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde