Patrick K. O'Brien wrote:

>  More unfortunate is the option parameter, which only applies to
>  BoxSizer, but is defined in the Sizer parent class, and isn't easily
>  ignored because it is the second parameter and comes before the flag
>  and border parameters.  And the wxWindows docs don't call it option,
>  they call it proportion, which is a bit more descriptive since it
>  determines the proportion of space allocated to the item in relation
>  to the space requested by all items in that particular BoxSizer.
>  
>  I'm starting to think the entire sizer API is ripe for an overhaul.
>  If ever there was a place to deviate from wxWindows, surely this is a
>  pretty good one.

I've never seen the point of defining Add in wxSizer if it doesn't have 
the same interface in all subclasses.

Personally, I'd rather see the sizer API fixed in wxWindows as well 
(with appropriate backward compatibility), but I don't know what the 
chances of that happening are.  By the way, there has been a lot of 
discussion on the wx-users list lately of suggestions for wxWindows 3 
(including a wx namespace with wx::Frame, etc.) so it would probably 
make sense for some of the principals here to be involved in that 
discussion as well.

David


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