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

[Simon Edwards]

On Friday 08 September 2006 01:51, David Boddie wrote:
> On Thursday 07 September 2006 23:03:14 +0200, Simon Edwards wrote: 
> While it would be nice to have ready made bindings for each new KDE release,
> it's going to take some willingness on the part of the core KDE developers
> to plan for this in their release schedules. (Maybe they already do.)

Well, the 3.5 release schedule looked like this:

August 1st, 2005: Officially close of feature list
August 25th, 2005: branches/KDE/3.5 is feature frozen
September 5th, 2005: Message Freeze
September 13th, 2005: Beta1 is prepared
October 12th, 2005: Beta2 is prepared
November 9th, 2005: Release Candidate 1
November 29th, 2005: Targetted Release Date

http://developer.kde.org/development-versions/kde-3.5-release-plan.html

New APIs should be in place by feature freeze, which in this case leaves 3 
weeks till the first beta, the second beta was a good month after the first. 
3 weeks isn't a lot of time to wrap and test a new API for the first beta, 
but there is quite a lot of time when you take the 2nd beta and the RC into 
account.

Jim, I'm guessing that most of the time required for developing PyKDE goes 
into testing on the different platforms and distros? I think that a small 
group of people running different platforms and distros could help out a lot 
just by compiling PyKDE from KDE's SVN. Not to mention people like Adriaan de 
Groot who routinely recompile all of KDE's SVN on different platforms.

> 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

You mean "too late before release" I assume.

> release, 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. Or at the very least make a 
freezing APIs *strongly* recommended. Again it is hard to tell how it will 
work out w.r.t. the work. I don't know how super Phil's super code generation 
tool is. :)

> Although KDE 4 looks like it's starting to take shape, I can't believe that
> there's not going to be a lot of flux in the APIs before they stabilize into
> a form that provides the features that have been promoted in various places.
> I don't think it's worthwhile synchronising just yet, though it's possible
> that some groundwork could be put in for the future.

oh, I'm not saying that we should fire up the compiliers right now for 
KDE4. ;-) As Sebas said, it is still a bit early. After Akademy it might be 
better.

> We also need to work on increasing the range of developer tools available
> to make it easier for people to develop and deploy Python applications on
> KDE. This may come in the form of standalone GUI tools, or it may require
> work to add support to existing IDEs, but it seems to me that it's
> necessary.

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.

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

[1] http://www.simonzone.com/software/pykdeextensions/en/index.html

cheers,

-- 
Simon Edwards             | KDE-NL, Guidance tools, Guarddog Firewall
simon at simonzone.com       | http://www.simonzone.com/software/
Nijmegen, The Netherlands | "ZooTV? You made the right choice."