On Sunday 30 March 2008 03:44, Alexander Dymo wrote: > Once again, we'd better concentrate on writing great software. Reusing > the code, using existing free software as much as possible is one of > the ways to write great software. Why care about dependencies then? > Let's let people making distros think about that.
Simon Edwards pointed me to this discussion - Simon maintains the KDE svn version of PyKDE and uic for PyKDE, I maintain the tarball version that's available at riverbankcomputing.com and write the tool that generates PyKDE sip files from the KDE h files. Phil Thompson is the author of PyQt and sip, which generates the C++ bindings from sip files, and is the runtime that allows the bindings to function. I've been doing PyKDE since late KDE2, Simon since late KDE3 - Phil has done sip/PyQt and the original PyKDE since early KDE1 at least. Most of the large distros and FreeBSD (and sometimes Solaris) have packagers. I'm the guy who doesn't keep PyKDE up-to-date with KDE. Simon now has the tools to generate new PyKDE versions, so that should be less of a problem. If KDE maintains strict binary compatibility, that isn't much of a problem at all, because PyKDE lagging KDE simply means new classes/methods aren't picked up - previous apps should still work. However, one missing symbol in kdelibs (it happens) will break part or all of PyKDE if it's in one of the libs PyKDE binds. PyKDE probably has bugs. I just fixed KCoreConfigSkeletion, which is broken in the current PyKDE release. PyKDE bugs get fixed either when I write an app using it and find a bug, or, as in the case of KCoreConfigSkeleton, someone else finds it. I'd love to have unit testing for all of PyKDE (the C++ test code isn't usable for PyKDE), but PyKDE binds about 600 classes and 10k methods. So the person who suggested that more apps using PyKDE would make it better is essentially correct. Some of the nicest improvements have been user-supplied. I'm agnostic about whether KDE should have a core Python dependency. I agree with Alexander's earlier post about Ruby and Python as application languages - everything I write - PyKDE generation tools, my business accounting software, other stuff - is in Python. There's a great Python/PyQt/PyKDE IDE done by Detlev Offenbach called eric4, which includes a debugger that never crashes - if I hated Python, that would be enough motivation for me to use it. However I wouldn't overlook the "scripting" part of Python either. While PyKDE is a lot of overhead at runtime for the first instance (the 8MB cited sounds right, or maybe a little low) for a lot of people , the convenience or speed of development outweighs that. One of the most helpful things KDE could do to support other languages (without acquiring dependencies) would be to make plugins and similar things more easily writeable in other languages - for example, instead of requiring a specific .so lib, allow an .so lib that knows how to load an arbitrary Python script along with the interpreter (ie - pass the script name rather than looking for a specifically named .so lib). KDE3 Panel applets and extensions allowed that. You can't create .so libs from Python. I haven't looked at kross much yet, and maybe that will solve some of the problems, but some people would like to write plasmoids or ioslaves or other plugins in languages other than C++ and not have to write a C++ lib to use them. There were kate plugins using PyKDE for KDE3 and the same author may do them for KDE4. As far as porting to OLPC or other devices, I don't have much to contribute there, except to note that PyQt was available quite a while ago for the Sharp Zaurus (I believe Sharp - or someone - paid for the port). I'm only subscribed here temporarily, so feel free to email me if I don't respond to something. Jim _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
