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

[Jim Bublitz]

On Thursday 07 September 2006 14:03, Simon Edwards wrote:
> On Wednesday 06 September 2006 13:46, Hans-Peter Jansen wrote:
> > Am Dienstag, 5. September 2006 19:29 schrieb Joachim Werner:
> > > SUSE has been shipping with PyQt/PyKDE installed in the default
> > > system for quite a while. For PyQT/PyKDE 3 this was a no-brainer: The
> > > HP printer tools are installed by default and need them, so we have
> > > to install PyQt/PyKDE (or actually kdebindings3-python that contains
> > > them) by default, too. ;-)
> >
> > which reminds me that the official kdebindings3-python package of KDE
> > 3.5.4 is _way_ behind the current state of affairs.
>
> True. One of the main problems here is that the copy in KDE bindings needs
> to respect KDE's policies concerning binary compatibility between releases
> and minor releases, while at the same time SIP and PyKDE have been on their
> own schedule when it comes to things like breaking compatibility and
> bumping library revisions.
>
> Which brings me to a topic that I've been wanting to talk about for a while
> now: synchronising PyKDE with KDE itself and its schedule. What I would
> like to see in the future is KDE shipping each time with a complete and up
> to date version of PyKDE included. To make this happen PyKDE development
> would have to be opened up more. Jim has done a great job in the past
> developing and maintaining PyKDE, but to do ensure synchronised releases
> with KDE it is going to take more people to jump in and do what needs to be
> done before any given release. I'm willing to pitch in to see this happen,
> and I see that Pete has already put his hand up. ;-)
>
> Acceptance of languages like Python and Ruby for GUI development has
> increased a lot in the last couple of years. Kubuntu for example, relies on
> PyKDE as part of its base install. (It is needed for many of the
> configuration tools, and in the next release for the thier new power
> management applet). Python support as a standard, and first class part of
> KDE looks like the next logical step to me to help continue this trend.
>
> cheers,
>
> PS. Just the other day I came across this for the first time
> http://www.kumula.org/ .

I'm completely in favor of synching KDE and PyKDE - it's just not something I 
can do much about. For KDE3, it's stable enough (rate of change is slow 
enough) that if a few people knew how to write/modify sip files and use diff, 
it wouldn't be much of a problem. presip won't help that much if the work is 
split up.

For KDE4, I expect being able to generate the first round of code 
automatically will be a huge advantage. Depending on the rate of change in 
the kdelibs code after 4.0.0, again, for several maintainers it might be just 
about as easy to do manually. Phil maintained PyQt manually through the last 
Qt3 release - several (50 or so) of us ought to be able to do as well. 
Seriously - 2 or 3 maintainers splitting up module responsibilities would 
probably do it with decent communication and source control. I'm perfectly 
willing to provide help. I don't wanna be the boss though - I'm too 
unreliable.

It's unlikely that you can maintain a system which a) stays in sync with KDE 
and b) stays at the cutting edge of sip/PyQt, but I don't see why that would 
be critical - certainly the distributors are always a few revs behind, and 
people who need the cutting edge can still roll their own, especially if 
PyKDE is up-to-date with KDE.. There has always been a stable configuration 
that's usable, if not completely up-to-date with the latest sip changes.

My biggest wish is that more people would learn to use sip. It's not really 
very hard (I'm exhibit A), and the benefits of spreading that knowledge would 
eventually extend far beyond PyKDE, besides making PyKDE more maintainable by 
others.

And I agree that the use of PyKDE for third party applications is a serious 
support consideration - that concerns me more than staying in sync with KDE.

Jim