[PyKDE] Bindings and the KDE project
jbublitz at nwinternet.com
Thu Mar 25 05:30:01 GMT 2004
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
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
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
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.
More information about the PyQt