[wxPython-users] Re: Default Sizers, First Draft (was Re: [wxPython-users] Parent of wx.BoxSizer?)

[Christopher Barker]

Don Dwiggins wrote:
> I think there'd be a gain in simplicity and flexibility by completely 
> separating the tab ordering issue from the containment hierarchy and 
> from the layout mechanism.

Absolutely.

>  give each 
> control a "TabPrevious" and "TabNext" property, each holding a reference 
> to another control.  (This would allow several independent "tab 
> groups".)  If these properties are empty for a control, the tab key 
> wouldn't have any effect when that control has focus.

I like that a lot.

I was just messing with tab order for an app and found that, even for my 
simple case (all I wanted was for a few read-only text boxes to NOT be 
in the tab order), it was a pain in the *&^. In fact, it works 
differently on all three platforms, so I have not yet found a universal 
method.

> something like HTML's tables. This 
> is the one layout that I can think of offhand that can't be covered by a 
> hierarchy of box sizers -- you need the simultaneous row/column 
> structure, along with the ability to "span" rows and columns where 
> necessary.

That would be a GridBagSizer.

> I'd also offer a Panel subclass replacement for the StaticBoxSizer (this 
> one's always seemed a bit strange to me -- it's the one sizer that has a 
> visible component).

This would work well if we can solve the Tab order problem.

> I've never used the GridBagSizer, but I've seen a few messages now from 
> folks who have gotten frustrated with it.  Yes, it may be capable of 
> covering all cases, but is it the clearest/simplest way to do it?

I do think it needs a better API.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov