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 _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde