[PyKDE] Plans for PyKDE in KDE 4

Fri Nov 17 09:40:20 GMT 2006

Hi Simon,

Thanks for putting this together, it looks really well done and 
comprehensively. Some minor remarks inline, however.

On Thursday 09 November 2006 21:36, Simon Edwards wrote:
> Hello all,
>
> I've been talking to Jim Bublitz about plans for PyKDE in the up coming KDE
> 4. We, and I hope a lot of other people here, want PyKDE to be the best,
> most effective and most enjoyable way of developing KDE applications. 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.
>
> I've put together this message below explaining these plans in more detail.
> Once everyone here has a had a chance to give feedback or make corrections
> as needed, then I'll be sending this message on to the kde-core-devel list,
> the Technical Working Group and the broader KDE community in general.
>
> Feedback is appreciated.
>
> (Jim, you might want to read the Platform and Versioning sections again).
>
> cheers,
> Simon Edwards
>
> -----------------------------------------------------------
>
> 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.

Does this licensing include some agreement like the one regarding the FreeQt 
foundation, i.e. what happens if Riverbank goes belly-up?

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

Maybe address why it's been a PITA to compile for a lot of people ...

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

There is already a copy in the bindings module, so make sure it's clear what 
the difference will be.

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

The Technical Working Group is in fact only interesting when it comes to 
conflicts, so I'm not sure it's correct to address them directly. If 
possible, everything should be solved in the 'open community'.

> 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?)
>
> We also request that the TWG consider supporting the Python bindings as an
> official part of standard KDE releases.

I'd word that as:

"We'd like to promote the Python bindings as an official part of the standard 
KDE releases."

Sidenote: I've picked up from the discussion on kde-core-devel that at least 
one non-trivial application in KDE4 should use the bindings. In order to do 
that, we'd need a working set of KDE4 bindings soon, of course.

> Current status
> ~~~~~~~~~~~~~~
> The first production quality release of PyQt4, supporting Qt 4.0 was on 10
> June 2006. Support for Qt 4.1 was later released on 15 July. Jim Bublitz

In the meantime, Qt 4.2 support is there already.

> recently reported that he has completed the bulk of the work needed for an
> initial alpha release.
>
>
> [1] http://www.riverbankcomputing.co.uk/
> [2] http://www.simonzone.com/software/pykdeextensions/
>
> -----------------------------------------------------------

Hope to help,
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Political language [...] is designed to make lies sound truthful and murder 
respectable, and to give an appearance of solidity to pure wind. - George 
Orwell, 1984

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: not available
Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20061117/5f05cf02/attachment.bin