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

[Jim Bublitz]

On Friday 08 September 2006 01:26, Sebastian Kügler wrote:
> On Friday 08 September 2006 01:51, David Boddie wrote:
> > 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.
>
> In october, there will be a technical preview of KDE4 That's after aKademy,
> I excpect a lot of changes to be done there, especially WRT API issues,
> since those discussions make a lot of sense face-to-face. After aKademy, it
> should settle down a bit, although the APIs are probably still to be
> changed. At the moment, a couple of important things have not happened yet:
> Plasma is far from ready, Solid hasn't been merged, Akonadi (Ok, that's
> more comparable with kdepimlibs, but still) is not yet there...

> It would be nice, however, to have something to play with in the meantime,
> especially for those, that would like to ship their PyKDE when KDE4 is
> released, or shortly thereafter. But then I'm not the one who has to run
> after an unstable API. In that sense, it would make a lot of sense to
> maintain only one copy in a public place (KDE SVN?), so people can more
> easily help getting PyKDE into shape. As Jim said, it's not that hard to
> write the sip files, and given the active and helpful community around
> Py(Qt| KDE), I can imagine that it "just works".

I just want to clarify - to do the initial set of sip files for KDE4 will be a 
lot of work if done manually,  just because of the large number of files that 
need to be created. Once you have a base set of files, you can diff the h 
files for the next KDE version, and then just go through a much smaller 
number of files and apply changes and versioning conditionals. That's still a 
lot of work for one person over 10-12 modules, but split up between a few 
people, not too bad.

There's also the possibility of cleaning up the tools, so all that can happen 
automatically. There's really no reason you can't put in KDE4 h files and get 
PyKDE4 sip files out (except a small amount of handwritten code, a lot of 
which is cut/paste/change type names), except that it's been more efficient 
to manually patch the errors in output than to debug the tools.

The other problem is having an environment to compile and test the code - that 
turns out to be a big time consumer for me, especially if I'd have to compile 
KDE. Which is why I wait for rpms before upgrading PyKDE. On the other hand, 
PyKDE4 won't require all of the back-testing PyKDE 3 does now, which is the 
other big time cost.

Actually, thinking about this some more, the sensible thing to do would be to 
either fix or recreate the automation for generating code, and maybe I'll 
think about doing more of that. 

Jim