[PyKDE] ANN: SIP/PyQt v3.0pre1 - And a Question

Phil Thompson phil at river-bank.demon.co.uk
Sun Sep 30 14:34:55 BST 2001


I decided not to release v2.6.1 as PyQt has now been ported to Qt v3.

v3.0pre1 can be found at the usual place at
http://www.river-bank.demon.co.uk/software/private/. There is a copy of
PyQt for Qt v2.3.1 and another for Qt v3.0.0Beta6.

The SIP runtime library has changed so you need to upgrade this.

All of the existing Qt v2 classes have been ported to v3 - but anything
marked as obsolete has not been ported.  The following new v3 classes
have been added:

QCanvasSpline
QContextMenuEvent
QCheckTableItem
QComboTableItem
QDesktopWidget
QDockArea
QDockWindow
QIMEvent
QKeySequence
QRegExpValidator
QStyleOption
QTabletEvent
QTextEdit

The remaining new v3 classes will be added over the next few
weeks/months. If you have a particular requirement then let me know.

I've taken advantage of the change in major version number to introduce
a couple of incompatibilities, and I intend to introduce more before the
final release of PyQt v3.0.

- There are a 6 methods that have been renamed. In fact they now have
their proper Qt names. See the documentation for details.

- Anybody who is using SIP to generate bindings for other C++ libraries
will have to change any hand-written code. This is because
sipParseArgs() has been revised and now does all C++ to Python
conversions and not just type checks. This results in about 20% less
code being generated (and the hand-written code is simpler) but the new
version is incompatible with the old. I'll try and remember to send out
a note describing the changes once I'm sure I've got the changes right.

Now the question...

I want PyQt to reflect the splitting of Qt into logical modules more
than it does at the moment, but I'd like some feedback on how far to go.
At the moment the only classes split off into a different Python module
are the OpenGL ones. There are a couple of reasons for wanting to do
this:

- It's much easier to configure the build process for optional classes
(particularly for the Professional Edition of Qt).

- As Qt gets bigger I don't want to force that bloat onto scripts that
don't use those extra features.

The question is, how far to go? I will definitately put each of the
modules (Canvas, Network, OpenGL, Table and XML) that are only in the
Enterprise (and GPL) Edition into separate Python modules. The new SQL
module will also be separate. The documentation also describes Iconview
and Workspace modules - but also talks of the "base" modules (tools,
kernel, widgets etc) which, confusingly, includes the Iconview and
Workspace modules.

I'm considering the following options...

- Do the minimum and just create qcanvas, qnetwork, qxml etc modules
that sit alongside the existing qt module.

- Go to the other extreme and move everything around to create qt.tools,
qt.kernel, qt.widgets, qt.canvas, qt.network, qt.xml etc.

- A compromise to create qt.base, qt.canvas, qt.network, qt.xml etc.
(and then decide on whether QWorkspace goes into qt.base or
qt.workspace).

Opinions and other suggestions welcome.

Phil




More information about the PyQt mailing list