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

[Jim Bublitz]

On Saturday 09 September 2006 04:42, Simon Edwards wrote:
> On Friday 08 September 2006 23:42, David Boddie wrote:
> > 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.
>
> I see what you mean. Updates to the bindings in PyKDE won't be able beat
> the general KDE feature freeze. The dependancies just don't work that way,
> as you know. PyKDE will have to be an exception to the general rule, and
> we'll just have to explain this to the KDE release team in advance. They'll
> understand. :) I still think there is enough time between FF and release to
> get things updated and tested.
>
> Things and features that *don't* depend on the APIs in kdelibs should still
> obey FF though.
>
> > > 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. :-/
>
> Last minute API changes shouldn't happen too often. It should be possible
> to monitor commits to kdelib header files.

Actually, it should be possible to generate PyKDE on the fly from the kdelibs 
h files. That's what sip does now - it generates C++ on the fly when you 
build PyQt or PyKDE. This would just move the process back one level.

I would be hesitant to claim presip is as reliable as sip, but if you remove 
the need for versioning, it already works pretty well. Otherwise, someone can 
develop a new tool, or modify an existing one to do the same thing.

The one thing you need to have is a lot of knowledge from the previous PyKDE 
version - handwritten code, methods to ignore, docs, etc. That info is all in 
the previous version's sip files, or could be encapsulated in metafiles in 
XML or whatever. presip can be modified to output XML too - I've just never 
bothered to do it and don't have a spec for it.

So basically, you would create a base PyKDE version that's complete. At build 
time, you run a tool to generate new sip files from the latest kdelibs, and 
combine with the info stored in the previous version (but don't do versioning 
as such). After that, the build process is the same as it is now. The new sip 
files (after any manual fixes) become the new "base" version. While you 
always have a valid set of sip files (if you use those instead of some 
metafile solution) that could be built, you always generate a new set to the 
current kdelibs state each build.

You might have to modify the tool or project files after the code freeze in 
some rare cases to satisfy last minute changes (if they require handwritten 
code, or use syntax the tool doesn't know how to handle), but I'd consider 
those to be "bug-fixes", and it seems to me the development process should be 
able to allow those. There are some potential problems, but not many and none 
too serious.

Longer term, any PyKDE version could be built the same way, so the idea of 
distributing a tool and metafiles instead of sip files would seem like a 
reasonable solution, especially since, in theory, I'd never have to write a 
new version of PyKDE again :) And everybody would be up to date except for 
some handwritten code (and a lot of that could be built into a tool also - it 
was at one time, but I pulled it out). 

There are some non-trivial details to work out, but I think it's worth 
considering.

Jim