book on wxPython?

[Grant Edwards]

In article <js4hn1-mo7.ln1 at 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!