Patrick K. O'Brien wrote:
>  What do the rest of you think about this proposal?

I agree with the proposal. I agree with your assertion that changes like 
this are better done as we think of them instead of later.


>  What issues have I missed?

Sounds like you're preserving backwards-compatibility, which is a plus. 
Seems like a wx.Size should be just as acceptable as a tuple.


Chris Barker wrote:
>  That's because they are not documented or used iont he Demo. I wish I
>  knew they existed, as I would have used them. 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().

I think the overloading *was* confusing when the width and height were 
in there directly. Using Add() always felt awkward. But with Patrick's 
proposal, the signature is essentially the same: you're adding one 
thing.

>  Should I persue this? Are folks interested?

I'm always interested in API improvs. I'm even cooking up a few of my 
own.  :-)

I also found Will Sadkin's comments on what makes sizers confusing to be 
quite cogent.


Patrick K. O'Brien wrote:
>     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.

I object. :-)   This feels inconvenient and artificial. It's not even 
clear to me from the outside why a sizer needs to wrap things in a 
sizer item anyway. Windows, sizers and tuples are already different 
types with their own methods and such. But if the implementor of sizers 
needed to this, then let it be a private implementation thing.

Patrick K. O'Brien wrote:
[snip]
>  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 agree again. It wasn't until you described the sizer odditities that I 
finally understood why using sizers always feels like voo doo.

Patrick K. O'Brien wrote:
>  While I'd like the APIs of the two projects to be as close
>  as possible, in the end I think good design should prevail and is
>  more important than strict compatibility.  But that's just my own
>  personal opinion.

I just wanted to second that.


-- 
Chuck
http://ChuckEsterbrook.com


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