book on wxPython?

[Grant Edwards]

Can anybody recommend a good book on wxPython? Are there any
books on wxPython?

I've been trying to learn wxPython and/or wax for a few weeks,
and I'm just not getting it. [I wrote and shipped one small
wxPython app a couple years ago, and it was a cut/paste, trial
and error sort of exercise.]

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.

For example, I'm still confused about how to tell what the
"parent" of a widget should be. When you put a StaticBox in a
Panel, the Panel is the parent of the StaticBox. When you put
SomeOtherWidget in the StaticBox, why is the parent of
SomeOtherWidget the Panel and not the StaticBox?

And what about sizers? They seem to be a sort of parallel,
phantom tree of widgets that's stuck on the side of the real
tree of widgets, while other GUI toolkits treat layout widgets
(grids, hboxes, vboxes, etc) as a "first-class" widgets that
reside in the same tree as the widgets that actually draw
stuff.

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'm also still reading stuff on wiki.wxpython.o rg, but Wikis
always seem so fragmented...

[1] I still think the hbox/vbox/glue abstraction used by
Trestle was one of the easiest to use. Probably because
I've been using TeX and LaTeX for 25 years.

--
Grant Edwards grante Yow! How do I get HOME?
at
visi.com

[Ryan Paul]

On Sat, 15 May 2004 03:32:00 +0000, Grant Edwards wrote:

Can anybody recommend a good book on wxPython? Are there any
books on wxPython?
I have a copy of the python2.1 bible. Its a bit outdated, but it has a
really good section on wxpython. Its by no means a comprehensive
exploration of wx, but gives a good presentation. The book is nice to have
around for other things too, it has good examples, and it really helped
extend my understanding of several facets of python.

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. 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.
People say that WAX fixes this. (I've never used it)
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!

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.

--SegPhault

[Grant Edwards]

In article <pa************ *************** *@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.

[F. GEIGER]

Mark Hammond's book "Python Programming on Win32" helped me a lot in
entering wxWindows (oops, sorry, wxWidgets of course) programming. A 2nd
source of "no, how?" I can recommend is the wxPython Wiki with a few
essential recipies. And the wxWidget help coming with wxPython is a good
resource a soon as you were able to get started.

HTH
Franz GEIGER

"Grant Edwards" <gr****@visi.co m> schrieb im Newsbeitrag
news:sl******** ***********@gra nte.rivatek.com ...

Can anybody recommend a good book on wxPython? Are there any
books on wxPython?

I've been trying to learn wxPython and/or wax for a few weeks,
and I'm just not getting it. [I wrote and shipped one small
wxPython app a couple years ago, and it was a cut/paste, trial
and error sort of exercise.]

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.

For example, I'm still confused about how to tell what the
"parent" of a widget should be. When you put a StaticBox in a
Panel, the Panel is the parent of the StaticBox. When you put
SomeOtherWidget in the StaticBox, why is the parent of
SomeOtherWidget the Panel and not the StaticBox?

And what about sizers? They seem to be a sort of parallel,
phantom tree of widgets that's stuck on the side of the real
tree of widgets, while other GUI toolkits treat layout widgets
(grids, hboxes, vboxes, etc) as a "first-class" widgets that
reside in the same tree as the widgets that actually draw
stuff.

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'm also still reading stuff on wiki.wxpython.o rg, but Wikis
always seem so fragmented...

[1] I still think the hbox/vbox/glue abstraction used by
Trestle was one of the easiest to use. Probably because
I've been using TeX and LaTeX for 25 years.

--
Grant Edwards grante Yow! How do I get HOME? at
visi.com

[Thomas]

Hi,

try making a small App with Boa Constructor and
look at the code afterwards

just my 2 (Euro) Cents :-)
Thomas

[francois lepoutre]

> Can anybody recommend a good book on wxPython?

Are there any books on wxPython?

You're not alone waiting for the wxpython book.

As a lot of python users, i just learned python from
a couple of web resources, referring to books later
and mostly for reference or unusal tricks.

Learning a UI, specifically when you're not an
MFC (or unix eq.) guru, is another matter.

I expect that this wx* book, whatever its quality
and price, would make more to the project than
additional web resources or bug fixes...

At some stage, when dealing with complexity,
you 've got to:
-solution 1, expect a quantic leap in terms
of "making the thing simpler", something like
a python way for UIs;
In view of the recent discusssion on the wxpython
mailing lists, it looks like the chances of a massive
"simplification " are getting dimmer over time..
-solution 2 - read the carefully writtent book
before diving.

Dear O'Reilly, do you hear us?

François

[Aahz]

In article <sl************ *******@grante. rivatek.com>,
Grant Edwards <gr****@visi.co m> wrote:

Can anybody recommend a good book on wxPython? Are there any
books on wxPython?

http://groups.google.com/groups?selm...enetserver.com
--
Aahz (aa**@pythoncra ft.com) <*> http://www.pythoncraft.com/

Adopt A Process -- stop killing all your children!

[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

[Grant Edwards]

In article <js************ @home.rogerbinn s.com>, Roger Binns wrote:

Ok, now add printing, drag and drop and comboboxes.
No thanks. I don't do printing or drag and drop. Or
comboboxes now that I think about it. My needs are fairly
simple, and Tkinter would suffice nicely, except that the
non-native look and feel seems to confuse Windows users.
You'll find you can't or you have to use external libraries
with Tkinter.
Moot. [For me.]
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.
I know. I'm paying the price, I feel like I don't get any
benefits.

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!

What are all the calls that look like parent.AddWindo w(child,...)?
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.

I don't think that's a good excuse for what appears (to me) to
be a fragile API. The purpose of an API is to hide 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.
Like I said, I think Wax is a vast improvement. I'd like to
help out with Wax, but I'm having a tough time finding basic
documentation on wxPython so that I can figure out why some of
the Wax classes don't behave as intended.

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.

Thank you!

Where do I find the documentation that explains things like
that? Teasing it out of people on Usenet is obviously a waste
of everybody's time.

All I can find is documentaiton on the class hierarchy. I've
looked at demo source code, but am having a tough time figuring
out why things are written certain ways.
For some gui toolkits the last two are combined.
For all the ones I've used in the past, the last two are
combined. Your posting is the first place I've seen it
explained explicitly that the control and layout hierarchy are
separate in wxPython. That probably explains most of my
confusion over the parent/child linkage. Not being aware that
there are two separate hierachies involved where I'm used to
one, it looks like there's a lot of odd redundancy involved in
setting up things.
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).
That's true.
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.
I guess those warts must be from some of the "underneath s" I've
never worked with.
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.
I agree (obviously).
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.

And I'm trying to find information to help me work on that.

--
Grant Edwards grante Yow! All right, you
at degenerates! I want this
visi.com place evacuated in 20
seconds!

[Andreas Kostyrka]

Am Sa, den 15.05.2004 schrieb Grant Edwards um 19:23:

In article <js************ @home.rogerbinn s.com>, Roger Binns wrote:

Ok, now add printing, drag and drop and comboboxes.
No thanks. I don't do printing or drag and drop. Or
comboboxes now that I think about it. My needs are fairly
simple, and Tkinter would suffice nicely, except that the
non-native look and feel seems to confuse Windows users.

That's the price you pay for having a nice API that is implemented
without "native" widgets. wxWindows (and wxPython upon it) is "more
complicated" because it has to deal with a number of native
implementations . By the way, wxWindows does a API model that is
relativly close to Windows developement ;)

You'll find you can't or you have to use external libraries
with Tkinter.

Moot. [For me.]

Not exactly. While you do not need printing and drag-n-drop, you checked
the "native look" item above. So Tk is not a sensible solution for you.

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.

Like I said, I think Wax is a vast improvement. I'd like to
help out with Wax, but I'm having a tough time finding basic
documentation on wxPython so that I can figure out why some of
the Wax classes don't behave as intended.

Well, read the wxWidgets docs. ;)

Andreas
--
Andreas Kostyrka
Josef-Mayer-Strasse 5
83043 Bad Aibling