Chris Barker <Chris.Barker@[...].gov>  writes:

>  "Patrick K. O'Brien" wrote:
>  
>  > This change only effects code that uses the wxPython variants, and I
>  > wasn't able to find any examples that did.  For instance, the examples
>  > on the wiki use Add(...), not AddWindow(...) or AddSizer(...).
>  
>  That's because they are not documented or used iont he Demo. I wish I
>  knew they existed, as I would have used them. 

I'm documenting them now.  That's how I discovered these variations.

>  Personally, I find this kind of overloading to be more confusing
>  than helpful, so I'd ratyher keep AddWindow(), AddSizer(), etc, and
>  depricate the Add().

Hmmm.  Why is that?  Python is full of full of functions and methods
that accept objects of multiple types: dir(), str(), list(), len().
And I don't find the differences between AddWindow(), AddSizer(), and
AddSpacer() to be significant.  What is significant is the redundancy
in documenting these methods, since they all do basically the same
thing -- add an item to the list managed by the sizer -- but take many
parameters than require a good deal of explaining.  So I'm genuinely
curious to know why you would favor the specific methods.

>  That being said, if we're going to keep the "overloaded" Add(), I do
>  like your change a lot. One thought is to have a "spacer" object, but if
>  there isn't anything useful to put in it other than two integers, then I
>  suppose that's a bit silly, and a tuple would be fine. After all, I can
>  always write code like:
>  
>  SmallSpacer = (2,2)
>  ...
>  MySizer.Add(SmallSpacer, ...)

Internally there is a SizerItem class with IsSizer(), IsSpacer(),
IsWindow() methods, but you aren't supposed to create SizerItem
instances directly.  They get created when you Add items to the sizer.
I think it would be a bit more Pythonic (as in "explicit is better
than implicit") to create SizerItem instances and then send them to
the Add() method.  In that case, the Add() signature would be very
small:

    def Add(self, item):
        """Add SizerItem instance to sizer."""

But this gets us much farther from the wxWindows API.  I wouldn't
mind, but others might object.

>  A couple of years ago, I wrote a little treatise on wx-dev about a nicer
>  API for sizers. Being a Pythonista, and having only a smattering of C++
>  knowledge, I came up with something that used a lot of keyword
>  arguments, and really couldn't be implimented in C++, but would have
>  been pretty nive for Python. Robin expressed interest in including it if
>  I wrote it, but of course, I never got around to it. 
>  
>  Is there interest in a thicker wrapper around Sizers that will make them
>  easier to understand, I'll try to dig up that email and we can start the
>  discussion. The obvious downside is that then wxPython Sizers would have
>  a different API than wxWindows sizers, and that would have impilcations
>  for docs and GUI builders.
>  
>  Should I persue this? Are folks interested?

I'm definitely interested.  I think it's at least worth discussing.  I
don't think wxPython programs make enough use of sizers, in part
because they aren't documented sufficiently and explained enough.  I'm
working on docs and examples now.  But a more Pythonic implementation
might help as well.  Perhaps as an alternative on top of, or in
addition to, the implementation that mirrors the wxWindows API.

-- 
Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@[...].org
For additional commands, e-mail: wxPython-users-help@lists.wxwindows.org