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

[Jim Bublitz]

On Thursday 07 September 2006 16:51, David Boddie wrote:
> On Thursday 07 September 2006 23:03:14 +0200, Simon Edwards wrote:
> > On Wednesday 06 September 2006 13:46, Hans-Peter Jansen wrote:
> > > 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.
>
> This independence is actually quite useful in other respects, particularly
> for SIP.

Yes. 

> > 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.
>
> While it would be nice to have ready made bindings for each new KDE
> release, it's going to take some willingness on the part of the core KDE
> developers to plan for this in their release schedules. (Maybe they already
> do.)
>
> Reading through the SIP files for PyKDE, you find lots of information about
> the way the KDE APIs have evolved over time. If the bindings were too
> closely tied to some schedule where development was frozen too early before
> a release, there wouldn't be enough time to update the bindings to include
> changes like these, unless the tools to generate the bindings could manage
> it automatically. I think a staggered release schedule would work much
> better.

Yes, somewhat. Depends on the time distribution of changes. If they bunch up 
against the code freeze, PyKDE is screwed, at least in terms of being fully 
up to date. If they're spread out, you could probably catch most of them. KDE 
has been pretty good about maintaining a compatible API (eg - few if any 
methods/classes deleted, few argument changes to methods except as an 
overload, etc). That makes a slightly out-of-date PyKDE still usable. 

I would think any kdelibs dependent app has the same problem.

However KDE and also distributions haven't been perfect, and it doesn't take 
much of a change to break PyKDE. Still, I think it's less of a problem now 
than early on. 

> 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.
>
> > 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. ;-);-)
>
> I had hoped to spend more time on PyKDE, apart from recent visits back to
> old plugin projects, but I'm spending a lot of (free) time these days
> working to give PyQt4 more exposure.
>
> > 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.
>
> We also need to work on increasing the range of developer tools available
> to make it easier for people to develop and deploy Python applications on
> KDE. This may come in the form of standalone GUI tools, or it may require
> work to add support to existing IDEs, but it seems to me that it's
> necessary.
>
> > PS. Just the other day I came across this for the first time
> > http://www.kumula.org/ .
>
> It's already in the list of known applications:
>
>   http://www.diotavelli.net/PyQtWiki/SomeExistingApplications
>
> Feel free to add any more you find to that list.
>
> David
>
> _______________________________________________
> PyKDE mailing list    PyKDE at mats.imk.fraunhofer.de
> http://mats.imk.fraunhofer.de/mailman/listinfo/pykde