book on wxPython?

[Grant Edwards]

In article <pan.2004.05.15.03.52.15.667940 at sbcglobal.net>, Ryan Paul wrote:

> I have a copy of the python2.1 bible. Its a bit outdated, but
> it has a really good section on wxpython. [...]

Thanks, I'll check into it.

>> wxWindows seems to be more low-level than the other GUI
>> toolkits I've used (Tk, GTK, and Trestle[1]), and there are
>> all sorts exposed details in wxWindows/wxPython that I find
>> weird.
> 
> wxWindows is far from low level.

For an example of what I mean by low-level, there's a "hello
world" example from an O'Reilly book I ran across earlier this
evening: <http://www.onlamp.com/lpt/a/196>. The Tkinter example
is 5 lines of code and includes a button that executes a
command when it's pushed.  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).  With Tk, a lot of the low-level
details are handled automatically, but in wxWindows, you have
to do them manually. Perhaps that gains you flexibility, but if
you don't need that flexibility, all it gains you is pain:
something that's one line of code in Tk seems to be typically
three or four lines of code in wxPython.

Another example: When you create a widget you have to tell it
who its parent is.  Then in a separate operation, you have to
tell the parent about the child.  Why is the link between
child/parent set in two places?  That's just a bug waiting to
happen: splitting up a single piece of information and putting
the two halves in two different places in the source code where
they have to be maintained in concert has always proven to be a
bad thing in my experience.  Why can't the operation where you
add a child to a parent also add the parent to the child?  Does
the child actually need to know who its parent is during the
interval between the child's creation and the child being added
to its parent?  Perhaps it does.  Is there an advantage to
doing the parent/child linkage in two separate operations?
Perhaps there is.  But when there's no explanation of what the
extra complexity/fragility buys you, it just looks sort of
broken and "low-level".

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. Again, there is some added
flexibility to the wxWindows approach, but I don't need that
sort of flexibility for the apps I write, so all I get is the
fun of writing triple the lines of code.

It's sort of like C vs. Python: C is a lower-level language, so
you have more flexible control over many things.  That
flexibility is expensive: you have to write more lines of code,
and that code is much harder to read, debug, and maintain.
Since the programmer is responsible for more of the details,
more of the details are wrong.

> it is a cross-platform compatible wrapper that sits on top of
> other toolkits. (Gtk on linux, for instance) It seems
> 'low-level' because the python bindings have very unpythonic
> syntax.

No, not just the syntax, but some of the basic architectural
design seems to be more low-level to me.  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.

> People say that WAX fixes this. (I've never used it)

I'm trying out wax, and it's definitely an improvement, but
it's not ready for production yet.  One of the widgets I want
to use doesn't work right, and due to the baroqueness of
wxWindows, nobody seems to know why.  I'm going to take a whack
at fixing some bugs, but I'll need to know a lot more about
wxWindows and wxPython and sizers and whatnot than I do now.
Hence the search for documentation.  One page I found said that
sizers were written in pure Python and therefore not part of
wxWindows, and for documentation on how to use them, you should
consult the wxWindows manuals.  Huh?

>> Anyway, I'd really love to find a good book on wxPython. I'm
>> still working through wxPython tutorials, and I've read
>> through some of the wxWindows ones (which are of limited value
>> for somebody steadfastly determined to remain clueless about
>> C++).
> 
> I applaud your efforts to stay C++ free, and I sincerely hope
> you have more luck in that endeavor than I did!

So far, so good.

> You might find that perusing wxPython examples helps more than reading
> those insidious c++ tutorials. The WxPython demo includes a comprehensive
> collection of examples, showing how to use just about every single widget.
> You might want to take a look at it.

I've been looking through those, and am still confused about a
lot of things (e.g. parent links and sizers). 

I printed out some wxpywiki pages to read in my spare time...

-- 
Grant Edwards                   grante             Yow!  I wonder if I ought
                                  at               to tell them about my
                               visi.com            PREVIOUS LIFE as a COMPLETE
                                                   STRANGER.