KDE 4 (was: [PyKDE] PyQt 4 on openSUSE)
simon at simonzone.com
Fri Sep 8 20:46:43 BST 2006
On Friday 08 September 2006 02:48, Jim Bublitz wrote:
> I'm completely in favor of synching KDE and PyKDE
> 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
The good thing about PyKDE is that once the base code is in place, it doesn't
take much coordination to keep it maintained. A small group of people keeping
an eye on PyKDE and the especially on developments in kdelibs around freeze
time, should be sufficent. Issues, breakage, bugs or new APIs can be reported
and coordinated on the mailing list (and via bugs.kde.org).
> 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.
What we want to be able to tell users and 3rd party developers is that a KDE
4.0 application written in Python will work fine on any 4.0+ version of KDE,
just like how it is with C++ apps. By just work fine, I mean that binary
packages containing SIP wrapped C++ classes and normal Python code should
stay working between versions. This seems to require that SIP and libsip
maintain BC during the KDE 4 series. I'd like to see mixed language
development supported. Is this realistic? or should no BC guarantees be
given? Phil, what are your thoughts about SIP binary compatibiity in the
The way that Python's module C API likes to evolve between releases also
complicates the picture...
> 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
> eventually extend far beyond PyKDE, besides making PyKDE more maintainable
Supporting mixed development would make using sip a lot more attractive, and
hence spread the knowledge. (You're right though, it is really not that hard
> 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.
can you elaborate?
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."
More information about the PyQt