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

[Jim Bublitz]

On Friday 08 September 2006 12:46, Simon Edwards wrote:
> 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 unreliable.
>
> 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).

Exactly right - it just takes a consistent commitment over time.

> > 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
> future?

> The way that Python's module C API likes to evolve between releases also
> complicates the picture...

I don't think binary compatibility would have been realistic a few years ago, 
as everything (KDE, sip, Python) was evolving. It might be possible now, but 
it seems odd to talk about binary compatibility for an interpreted language. 
On the other hand, I've had to make almost no changes to PyKDE's Python 
examples from KDE 3.0 forward - I don't think we've obsoleted much Python 
code over the years.

> > 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.
>
> 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 to understand).
>
> > 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?

When someone develops a PyKDE based app (HP printer stuff, SuperKaramba, 
etc.), I think we (I?) owe them a continuing, available platform for future 
releases. Whether that platform picks up new KDE features is less important 
to me than whether it's available and continues to support apps that already 
depend on it. I think the way PyKDE in kde-bindings has been handled has been 
exactly right in that respect - it's there, whether it keeps up with new 
classes, methods, or additions to PyKDE itself, and that's what I think is 
most important.

Jim