Plans for Python bindings in KDE 4

Wed Nov 15 20:12:15 GMT 2006

Hello all,

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 
bindings developers.

Feedback and questions are welcome.

Background
~~~~~~~~~~
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[1] 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 
years now.

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 
too.

During KDE 3, extra support was developed for plugins in Python (David 
Boddie), and support for i18n, building and installation[2] (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 
environment.

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).

Licensing
~~~~~~~~~
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.

Platform Support
~~~~~~~~~~~~~~~~
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 
as WIN32.

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?)

Current status
~~~~~~~~~~~~~~
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.

cheers,

Simon Edwards
This message is also reviewed and supported by Jim Bublitz.

[1] http://www.riverbankcomputing.co.uk/
[2] http://www.simonzone.com/software/pykdeextensions/

-- 
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
https://mail.kde.org/mailman/listinfo/kde-bindings