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.org, 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.com> schrieb im Newsbeitrag
news:sl*******************@grante.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.org, 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.com> 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**@pythoncraft.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.rogerbinns.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.AddWindow(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 "underneaths" 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.rogerbinns.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

[Roger Binns]

Grant Edwards wrote:

In article <js************@home.rogerbinns.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.

Then use whatever suits you best! To a certain extent this
is like the differences between accessing a file and just
reading lines, then moving up to structuring the information
in the file as CSV and finally a full fledged database.

Code that works with one step gets increasingly difficult
to work with the next step, unless you adopt a new library.
The APIs will assume increasing knowledge, and may even
require more code to use, but the capabilities available
to you in other bits of code increase.
I know. I'm paying the price, I feel like I don't get any
benefits.
It depends on what the future for your application is. My main
application (bitpim) runs on Windows, Linux and Mac. It makes
extensive use of threading, has custom controls, data manipulation,
printing, HTML integration etc etc. Obviously getting the initial
bit going took a little longer than Tkinter, but after the first
week or so the other parts were a lot easier and I haven't had
to say no to functionality (such as printing, drag & drop, HTML
etc).

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

What are all the calls that look like parent.AddWindow(child,...)?

Ah, that is to do with the layout hierarchy, which has nothing
to do with the containment hierarchy. Most people just
use the sizer.Add method which is polymorphic.

BTW the layout hierarchy is optional - you can use absolute sizing
and positioning of your controls if you want. (And that is normal
for Windows apps - note how few dialog boxes you can resize! That
is a consequence of layout management being a pain using the
real Windows APIs.)
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.
Yes, but at some point controls, events and functions acting
on events have to be bound together, sometimes taking into
account the class, containment or layout hierarchies. I'll
admit that wxPython's isn't the most concise or most beautiful.
But they do work. They have never been a hindrance on my
productivity, and a suspect many other people's. But if you
have a better way of expressing that, after you understand
it all at a lower level then please propose it. (I can't
really think of any).

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.

They are actually quite hard concepts to explain, and various
tutorials, the online documentation and wikis do try to
explain them. I don't think any of them do a particularly
good job.

However do feel free to write your own explanation and
contribute it to the Wiki.
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.
You should post your questions on the wxpython-users mailing list.
Almost all questions are answered very quickly.
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.

There are arguments for and against combining the containment
hierarchy and the layout hierarchy. For wxWidgets it is that
the layout management is kept seperate from controls that
draw themselves. This makes controls less complicated since
they only have to worry about how to draw, and do not have
to worry about arbitrarily complex child widgets to layout.
Similarly layout management objects (aka sizers) only have to
worry about layout, and not about drawing.

I won't argue as to what is best, but do believe the wxWidgets
approach is reasonable.

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 "underneaths" I've
never worked with.

You should try the various native gui toolkits someday - stuff
like win32, MFC, Xlib, Motif. wxWidgets/wxPython is an absolute
joy compared to them.

The real masochist can try MFC on PocketPC. The MFC source,
the PocketPC documentation and what the code actually does
frequently differ.

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.

I would recommend you give wxPython 6 months even if it is hard.
It is always better to more thoroughly understand something
before wrapping it, or taking a different approach.

From my own experience, each time you try something new such
as one of the more complicated controls, printing, drawing,
clipboard, "virtual" data or writing your own control, then
there is a little bit of a learning curve. In many cases
the demo (which is often overlooked) helps tremendously,
the documentation helps a little, and just sitting there
and writing code brings about the final closure. But that
always happens to some degree with any toolkit.

The quality of the toolkit, the variety of widgets, and core
functionality keep getting better. The cold hard reality is
that using wxPython today means you can deliver an application
that will run on a large variety of operating systems, screen
sizes, characters sets and unicode, and work the way the user
of the operating system expects (drag and drop, printing,
clipboards, common dialogs etc). It costs you nothing,
there is no vendor lock-in, and there is a lively community
behind it. Suits me!

Roger

[Grant Edwards]

In article <ma************************************@python.org >, Andreas Kostyrka 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
For some values of nice. :)
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 ;)

Well I've never done Windows development (by "Windows" I assume
you mean MS), so that may explain some of my bewilderment.

--
Grant Edwards grante Yow! YOW!!! I am having
at fun!!!
visi.com

[Grant Edwards]

In article <cf************@home.rogerbinns.com>, Roger Binns wrote:

Then use whatever suits you best!
Everything seems unsuitable in different ways. Life's like
that. wxWindows is looking better.
It depends on what the future for your application is. My
main application (bitpim) runs on Windows, Linux and Mac.
Cool app by the way. I used it to load my phone list into my
brand-new LG VX4400 about a year ago. [Best damned cell phone
I've ever used, and I've been using cellular phones for 20+
years.]

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

What are all the calls that look like parent.AddWindow(child,...)?

Ah, that is to do with the layout hierarchy, which has nothing
to do with the containment hierarchy.

I just figured that out. It's something that's it's taken me
over two years to realize (well, I wasn't working with
wxWindows for most of that two years). Basic stuff like that
is what somebody needs to write down somewhere.
BTW the layout hierarchy is optional - you can use absolute
sizing and positioning of your controls if you want. (And
that is normal for Windows apps - note how few dialog boxes
you can resize!
Yup, that's a source of never-ending frustration when I am
occasionally forced to use MS-Windows.
Yes, but at some point controls, events and functions acting
on events have to be bound together, sometimes taking into
account the class, containment or layout hierarchies. I'll
admit that wxPython's isn't the most concise or most beautiful.
But they do work. They have never been a hindrance on my
productivity, and a suspect many other people's. But if you
have a better way of expressing that, after you understand
it all at a lower level then please propose it. (I can't
really think of any).
Not realizing that the containment and layout trees are
_separate_ is half of what made wxPython apps appear to be a
mess.

None of the tutorials I worked through ever mentioned that the
containment tree and the layout tree are separate. Perhaps
that fact was obvious to everybody else, but I missed it
completely. I thought I was constructing a single tree, and it
was taking twice as much code as I thought it should.

[I still think the whole integer ID thing should be hidden from
the programmer, but perhaps a light will come on one of these
days and that will then make sense to me as well.]

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.

They are actually quite hard concepts to explain,

Is this more or less right?

In Tk and Trestle and ??? there is a single tree of widgets.
Some widgets impliment behaviors, handle user input events
(mouse clicks, keystrokes, etc.) and draw stuff on the
screen. Some widgets just arrange and size their children.
Some do both.

By contrast, in wxWidgets there are two separate trees.

One tree contains widgets that impliment behaviors by
handling user input events and drawing stuff on the screen.
That tree is constructed by passing the 'parent' pointer to
widget classes as you create instances. [I'm still a bit
foggy on the function of the parent-child relationship in
wxWidgets.]

The other tree contains sizers that control the layout (size
and position) of things. That tree is constructed by calling
a sizer's .Add() method to connect child sizers to a node.

In TeX-speak, sizers are like hboxes and vboxes where the and
widgets are like glyphs. The sizer tree defines what's
contained in each box. In wxWindows, the glyphs are also
connected in a tree structure.

footnote: It's possible to write an application without
using a sizer tree by manually setting the
position/size constraint attributes of the nodes
in the widget tree. Using these constraints, you
can either hard-wire sizes and positions in pixel
units, or try to impliment resizing the same way
sizers do. The former is evil, Evil, EVIL, and
will make people assume you're a MS Windows
weenie. The latter won't work right and make you
crazy.

The two trees are connected to each other in two ways:

1) by calling widgetInstance.SetSizer(sizerInstance). For
most simple cases, this is done just once to connect the
top (root) nodes of the two trees together.

2) by calling sizerInstance.Add(widgetInstance). This is
generally done for the sizer tree leaf nodes, but a node
in the sizer tree may have both widgets and other sizers
as children.

...
and various tutorials, the online documentation and wikis do
try to explain them. I don't think any of them do a
particularly good job.

However do feel free to write your own explanation and
contribute it to the Wiki.
Once I'm confident I understand things, I think I will try to
write a Tk to WxWidgets perception adjustment guide.
I won't argue as to what is best, but do believe the wxWidgets
approach is reasonable.
I think so as well. I just couldn't figure out what the
wxWidgets approach _was_.

I guess those warts must be from some of the "underneaths" I've
never worked with.

You should try the various native gui toolkits someday - stuff
like win32, MFC, Xlib, Motif. wxWidgets/wxPython is an absolute
joy compared to them.

I've done both plain Xlib apps and Xt apps with custom widgets.
Not fun, though I was pretty darned proud of my backgammon
board widget for Xt. The move animation was pretty cool. Too
bad it was controlled by the guts of the old brain-dead BSD
backgammon program -- it played a really lousy game.

Neither C nor Xlib/Xt is really suitable for modern end-user
application development. I've heard all sorts of nasty things
about Motif, so I never tried it.
I would recommend you give wxPython 6 months even if it is
hard. It is always better to more thoroughly understand
something before wrapping it, or taking a different approach.

I'm definitely going to stick with it. I blundered my way
though writing and shipping one small wxWindows app a while
back. Now that I've figured out the two-tree thing, it should
be easier.

--
Grant Edwards grante Yow! How many retired
at bricklayers from FLORIDA
visi.com are out purchasing PENCIL
SHARPENERS right NOW??

[Roger Binns]

Grant Edwards wrote:

Not realizing that the containment and layout trees are
_separate_ is half of what made wxPython apps appear to be a
mess.
Many programmers aren't even used to the idea of layout
hierarchies. It is very ingrained of you have ever done
Tk or Motif, but not something you will know about as a
Windows programmer.
Perhaps that fact was obvious to everybody else, but I missed it
completely.
I don't think it is obvious at all. There is an overview about
them in the doc, as well as some pages in the wiki.
[I still think the whole integer ID thing should be hidden from
the programmer, but perhaps a light will come on one of these
days and that will then make sense to me as well.]
I use them because I have menu items, toolbar buttons and buttons
in HTML that all need to reference the same thing. An integer
ID does the trick nicely.
[I'm still a bit
foggy on the function of the parent-child relationship in
wxWidgets.]
A child widget is within its parent - it will be clipped to
its parent, and is drawn on top of its parent. Some events
(eg command events) are delivered to a widget and if it
doesn't handle them then sent up the containment hierarchy.
I've heard all sorts of nasty things
about Motif, so I never tried it.
I worked for the company that at one point had 70% of the
worldwide Motif market. At that time it had i18n features,
a resource system noone used (not the same as Xt resources,
but more like XRC in wxWidgets), and portability to the
many flavours of UNIX. (I once used Sony UNIX - yes it
really existed).

Then CDE came along and the rest is history.
I'm definitely going to stick with it. I blundered my way
though writing and shipping one small wxWindows app a while
back. Now that I've figured out the two-tree thing, it should
be easier.

The best advice I can give you is to seriously examine the
XRC stuff. The XRC editor even comes with wxPython. That
will let you abstract out your user interface code (especially
the issues to do with layouts and parent relationships).
I just wish I had done it.

Roger

[Roger Binns]

Andreas Kostyrka wrote:

By the way, wxWindows does a API model that is
relativly close to Windows developement ;)

The real Win32 API is based on the Win16 API which was a reasonable
design in 1983, but had a lot of premature size and performance
optimization. That premature optimization is extremely cruddy
now. MFC was a C++ wrapper that tried to do things more sensibly
(aka object oriented) but was constrained by the C++ language
of the time and the underlying Win32 API.

That said, MFC isn't *bad* a toolkit to base something like the
design of wxWidgets on. And wxWidgets has gone through two
major versions now and has significantly refined things.

Roger

[Grant Edwards]

On 2004-05-17, Roger Binns <ro****@rogerbinns.com> wrote:

I'm definitely going to stick with it. I blundered my way
though writing and shipping one small wxWindows app a while
back. Now that I've figured out the two-tree thing, it should
be easier.

The best advice I can give you is to seriously examine the XRC
stuff. The XRC editor even comes with wxPython. That will
let you abstract out your user interface code (especially the
issues to do with layouts and parent relationships). I just
wish I had done it.

Thanks. I'll take a look at it. Right now I'm still trying out
Wax. For what I'm working on right now it seems like a good
solution.

--
Grant Edwards grante Yow! Hmmm... an arrogant
at bouquet with a subtle
visi.com suggestion of POLYVINYL
CHLORIDE...