book on wxPython?

[Roger Binns]

Grant Edwards wrote:
> The wxPython "hello world example"
> is twice as many lines of code and is just an empty frame: it
> doesn't even include the button (that would have made it three
> times as many lines of code).

Ok, now add printing, drag and drop and comboboxes.  You'll find
you can't or you have to use external libraries with Tkinter.
The price you pay for wxPython's flexibility and functionality
is that you have to be a little more specific in telling it
what you want to do.

> Another example: When you create a widget you have to tell it
> who its parent is.

Note that this is true of all gui toolkits at some point.
You have a containment hierarchy and have to specify it.
Eg a button is inside a text widget is inside a frame.

> Then in a separate operation, you have to
> tell the parent about the child.

That is news to this programmer who has been doing
wxPython for 3 years!

I don't know where you got that from, but it simply isn't
true.  Call GetParent() and GetChildren() and you will find
that all the information is correctly managed automatically.

> For a final example, in a previous thread I already went on and
> on about the integer widget and event IDs and separate
> "linking" functions used to connect handlers, events, and
> widgets.  That seems much lower-level than just passing the
> callable when you create the widget or letting the widget
> object have attributes or get/set methods that can be used to
> set up the callable for an event.

That just happens to mirror how the insides work.  It isn't too
much effort to make a higher level wrapper that does what you
want, but in all the years that wxPython has been available
few programmers have thought it would improve their productivity,
quality or other code attributes.  One example you have already
seen of someone who thought it would is Wax.

> Sizers, for example,
> appear to be an afterthought, and you have to sort of stick
> them onto your widgets manually. That functionality is part of
> the fundamental design of other GUI toolkits and just happens
> automatically.

Generally the problem is that people don't understand that there
are three seperate hierarchives when dealing with GUIs.  There
is the classes of the various controls, there is the instance
hierarchy and there is the layout hierarchy.

For some gui toolkits the last two are combined.  If you have a
clean sheet original implementation then you can make that work
well as it imposes some constraints on the controls to keep the
two hierarchies the same.  wxWidgets doesn't have the luxury
of a clean sheet design (it has to work with the existing
widgets of the underlying platform).

In general you should view wxWidgets/Python as a pragmatic
approach to getting a fairly high common appearance and
functionality across multiple platforms.  Sometimes the
warts of underneath show through, but if you used the
actual underlying toolkit you would be exposed to them
anyway.

Some other people or companies decided to do a clean
slate thing and implement everything themselves, a
good example being Trolltech and Qt.  That is really
hard to maintain.  Tk also did this.  You can see
more of a consistency and less quirks in their
resulting APIs.

The good news is that Python does make it easy to
put wrappers around wrappers.  Most wxPython programmers
haven't felt it necessary, but if you do the
groundwork is already laid.

Roger