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

[Hans-Peter Jansen]

Am Donnerstag, 7. September 2006 23:03 schrieb Simon Edwards:
> 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.

Hmm, KDE 3.5.4 did break things here (at least the current openSuSE 
build on 9.3). Gingerly updating sip and PyQt for the next release 
should be possible and is fairly safe, as long as .ui modules get 
regenerated. The few remaining tweaks aren't any show blockers, do 
they? PyKDE is a different story, true. Jim does a great job, but has a 
much trickier work to do compared to Phil, because he as to cope with 
the evolution of _all_ underlying technologies: Qt, sip, PyQt, KDE (and 
I'm ignoring the ugly distro KDE patches for simplicity now), while he 
has to make his living from other things.. Not that I underestimate 
Phils work - that's the genius who made this all possible in the first 
place (from a Python centric POV).

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

Yep.

<dream mode>

What I would like to see is Phil's new sip generation tool (if he's 
willing to release it into the open world) applied to KDE, with the 
(possibly) missing pieces added from Jim's presip. That way, the 
maintainance work could be (at least semi) automated and reduced to an 
edible effort.

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

In a real bright KDE future, I'm convinced, that more than 50% of all 
KDE tools could be rewritten in Python without any disadvantages - but 
many positive side effects, we all know and appreciate.

</dream mode>

Pete