From kde-bindings Wed Nov 15 20:12:15 2006 From: Simon Edwards Date: Wed, 15 Nov 2006 20:12:15 +0000 To: kde-bindings Subject: [Kde-bindings] Plans for Python bindings in KDE 4 Message-Id: <200611152112.15990.simon () simonzone ! com> X-MARC-Message: https://marc.info/?l=kde-bindings&m=116362138117872 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@simonzone.com       | http://www.simonzone.com/software/ Nijmegen, The Netherlands | "ZooTV? You made the right choice." _______________________________________________ Kde-bindings mailing list Kde-bindings@kde.org https://mail.kde.org/mailman/listinfo/kde-bindings