[PyKDE] Bindings and the KDE project

[Jim Bublitz]

On Thursday March 18 2004 12:32, Simon Edwards wrote:
> On Thu, 18 Mar 2004 08:40 pm, Roberto Alsina wrote:
> > I'd love if emphasis switched from "getting PyKDE and PyQt
> > to cover all latesst and greatest Qt/KDE" to "let's keep
> > this working, even if some corner case breaks". That would
> > let me advice people to install it.

> That is kind of what I'm looking for here. A stable version of
> PyKDE/PyQt that will be available and working on whatever the
> current stable release of KDE is. Updates to this "KDE synced
> version" would be limited to bug fixes. If KDE 3.4 shipped for
> example with a couple extra APIs and PyKDE didn't support
> them, it seriously wouldn't bother me too much. I don't think
> that is real problem. What is important is that people can
> always run their Python+KDE apps.

> > But of course, it's up to Jim, Phil & co, since they are the
> > ones coding.

> Perhaps a large part of the solution would be stable releases
> of PyQt/PyKDE that matched the release/maintainence schedule
> of KDE itself. I suspect this would suit the distro packages
> better too.

> Phil and Jim are always free to develop and release stuff
> outside of the schedule, but the important thing is that end
> KDE users would have a base stable version always available.

Here's the basic problem as I see it. Right now, PyKDE needs to 
know the version of KDE you're running to compile. When you 
build an RPM it's built against a specific set of KDE libs. So 
for example, if new RPMs are built for KDE 3.2.1, they aren't 
backwards compatible to 3.2.0 or any 3.x.x < 3.2.1.

Making one HUGE assumption that the KDE libs themselves are 
backward compatible (eg something linked to KDE 3.2.0 should run 
against KDE 3.2.1), the way to go it seems to me is to have a 
PyKDE binary version for each "major" KDE release (eg 3.1.0, 
3.2.0).  There usually isn't much that changes in the minor 
releases (3.2.1, 3.2.2, etc) that people would be greatly 
inconvenienced by being forced to write to 3.2.0 (but KDE can 
still be upgraded on the user's system to get fixes for KDE). I 
can still make tarballs available for the minor releases for 
people who have to have the latest.

The potential problem is that PyKDE (unlike a typical 
application) uses *every* symbol in the kdelibs modules bound. 
If 3.2.1 drops/modifies a symbol from 3.2.0, most PyKDE modules 
won't load because of the undefined symbol.  One small change 
(eg add an arg to a method call, change in "virtual") is enough 
to break all of PyKDE. KDE may not do this (not sure), but 
distros do.

I saw Phil indicate in another msg that the current PyKDE won't 
build against KDE 3.2.1. I haven't gotten far enough to look at 
that yet, so I don't have an explanation. If 3.2.1 is backward 
compatible with 3.2.0, there isn't any reason why that should 
happen. Note that the way I do PyKDE, I never see this happen, 
because I always adjust versioning for each new release 
(automatically too) and never look at the backward compatibility 
issue.

Phil also indicates that PyQt is not perfect in this regard, so 
that adds another potential set of problems.

Otherwise, to provide binaries for all possible cases, you need 
one RPM (or deb or whatever other distro uses) for every distro 
for every version to cover all possibilities. That's assuming 
for PyKDE that any Qt/Python version problems don't come up.

The thing to test would be build PyKDE against KDE 3.2.0 and then 
test the binaries against 3.2.1. It should work.

The other issues with PyKDE are not what you might think they 
are. It takes maybe 10-15 hours to generate a new PyKDE version, 
assuming sip is unchanged.  Even upgrading presip for sip file 
generation because of sip changes only took a day or two.

The current delays are due to upgrading the build/install system 
and upgrading to new sip syntax and features.  Actual sip bugs 
maybe took a few days this time around, but usually I can work 
around those and they don't impact development a lot. Phil 
responds very quickly.  Phil has also indicated sip changes 
should not be a future problem, and I don't think the build 
system will be a future problem either.

The remaining time-consumer is testing builds against various 
distributions/versions of Python/KDE/Qt/g++ and related libs, 
etc. I apparently didn't do a very good job of that on 
PyKDE-3.8. That had a new build system (since discarded) and a 
lot of bugs. That means I have to install the various distros 
and KDE versions (for new KDE releases), and then 
build/debug/build, which is time consuming. Link problems only 
show up after a complete build, for example, and only one at a 
time. All distros I've tested have link problems (not all 
symbols defined in the h files are in the libs), although they 
usually only occur with major version changes. 

I've given this a lot of thought in recent months, and I don't 
see any way around most of this, but an 80%-90% satisfactory 
solution might be possible. Another alternative is to give PyKDE 
its own binary installer (similar to StarOffice/OpenOffice.org). 
That's workable but the installation files to cover all 
possibilities will also be StarOffice-sized and we don't have 
the bandwidth to support that.

I haven't caught up on the rest of the discussion yet, but I'll 
try to tonight or tomorrow.

I'm open to any changes people want to make. I'm just not 
encouraged that there are helpful changes to be made at the 
moment.

The other changes I'd like to consider is dropping kjs (and maybe 
one or two other of the current modules) and adding kab. kjs 
always turns out to be a lot of work for some reason, and I 
don't think anyone uses it. Also, the panel applet/plugin type 
stuff needs work too.

Jim