Plans for Python bindings in KDE 4
simon at simonzone.com
Wed Nov 15 20:12:15 GMT 2006
This message is to explain what the plans are for Python binding support in
KDE 4, and general support for KDE application development using Python.
Python support is going to be bigger and better than ever in KDE 4.
The main change is that PyKDE will be developed in the KDE subversion
repository, meaning that anyone is free to help develop, improve and test new
versions of PyKDE. There are also a couple of requests for the Technical
Working Group and kde-core regarding release policies which can help out
Feedback and questions are welcome.
The Python bindings consist of a couple of parts. The binding tool SIP which
is used to help generate the binding C++ code, PyQt, Python/Qt bindings which
use SIP. Both are produced by Phil Thompson at Riverbank Computing in the
UK, and are available under the GPL or via a commercial closed source license
which can be bought. This model is similar to Trolltech's of course. SIP/PyQt
has been available and in commercial use since 1998 and support the same
platforms as Qt itself.
PyKDE is a set of bindings like PyQt which targets KDE's libraries. It is
produced and maintained by Jim Bublitz. PyKDE has also been mature for over 5
One of the stumbling blocks for people wanting to try out PyKDE has been the
non-trivial amount of parts of the PyQt/PyKDE stack that need to be compiled
before one can begin programming KDE with Python. To help easy installation a
copy of SIP, PyQt and PyKDE was put in the KDE's kde-bindings module for KDE
3.3 and setup to compile as one piece.
Goals for KDE 4
The primary goal is to make sure that each version of KDE ships with complete
and updated set of Python bindings. To do this we will move PyKDE development
into the kde-bindings module in KDE's subversion repository. Jim Bublitz has
traditionally developed PyKDE as a one man team, releasing the software
releases and beta versions to the internet from his own workstation. Opening
up development will allow those who want to help, to be able to work on PyKDE
directly. This will also reduce dependency on Jim Bublitz. Although he has
done an excellent job developing and maintaining PyKDE over the years in his
free time, he is still one person who has other more important commitments
During KDE 3, extra support was developed for plugins in Python (David
Boddie), and support for i18n, building and installation (Simon Edwards).
Open development in KDE's SVN will mean that these kinds of projects can be
developed directly as a part of PyKDE; helping form a complete development
Shipping PyKDE as part of a KDE release helps remove confusion about which
version of PyKDE should be used with which version of KDE. This also helps
simplify development and testing, since it no longer be necessary to test a
release of PyKDE against multiple versions of KDE. (Each release of PyKDE has
traditionally supported multiple versions of KDE).
The core PyKDE 4 libraries will be LGPL licensed in conformance with KDE's
licensing policy and the rest of KDE's libraries. Supporting programs such as
code generators etc, may be GPL licensed.
All of the software components that PyKDE builds on, like Qt, Python, PyQt,
etc support a large number of platforms. PyKDE has supported the same
unix-like platforms that KDE has in the past. This makes it relatively
straight forward to add support to PyKDE for the new platforms in KDE 4, such
Binary Compatibility & Versioning
Application programmers using Python rarely have to worry about binary
compatibility. Python has had very good source level compatibility during the
current 2.x series of releases.
Since people and distributions don't move to newer versions of Python at the
same time, it will be necessary that PyKDE support the most popular versions
of Python. For example, right now that would be 2.3, 2.4 and 2.5. Thankfully
SIP handles this for the most part automatically.
There is one situation where the picture becomes more complex and that is for
applications that use a mix of Python code and their own C++ classes. For
example, an application that uses a C++ class for rendering a complex graph,
but also uses PyKDE and Python for the rest of the GUI. The application
developer is this case would use SIP to create their own bindings for their
graph rendering C++ class.
People compiling and packaging mixed language applications need to keep in
mind that a compiled SIP binding for a C++ class depends on the version of
the SIP API that it was compiled with. It is not anticipated that the SIP API
will need to be changed in a backwards incompatible way any time soon. But
this is not guaranteed by Riverbank Computing.
At the time of writing there are only two known pieces of widely distributed
software that depend on the SIP API once compiled. These are PyQt and PyKDE
themselves. It is currently not possible to install multiple versions of the
SIP API into one Python installation. Although it is possible to install
different versions of Python (e.g. 2.4 and 2.5) at the same time, and then
install different SIP APIs into each Python installation.
In summary, if the SIP API needs to break backwards compatibility it may then
be necessary that all software that depends on SIP API be recompiled.
Requests for the Technical Working Group
Keeping bindings up to date and working for a new KDE release can be tricky
since any new APIs that need to be "wrapped" ideally need to be in place and
frozen before bindings can be created and tested.
Policy changes that would aid binding development:
* Feature freeze should also mean API freeze for libraries. Any new libraries
that expose a public and supported KDE API should be frozen as early as
possible to give binding developers time to do their work.
* API changes during feature freeze, and leading up to a release need to be
clearly communicated to bindings developers. If it is necessary to change an
API while leading up to a release, then bindings developers need to be
informed. (Perhaps an extra command in SVN commit messages warning about a
change in API / BC?)
The first production quality release of PyQt4, supporting Qt 4.1 was on 10
June 2006. Support for Qt 4.1 was later released on 15 July. Jim Bublitz
recently reported that he has completed the bulk of the work needed for an
initial alpha release.
This message is also reviewed and supported by Jim Bublitz.
Simon Edwards | KDE-NL, Guidance tools, Guarddog Firewall
simon at simonzone.com | http://www.simonzone.com/software/
Nijmegen, The Netherlands | "ZooTV? You made the right choice."
Kde-bindings mailing list
Kde-bindings at kde.org
More information about the kde-core-devel