book on wxPython?

[Grant Edwards]

In article <cfcjn1-6ue.ln1 at 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??