[wxPython-users] Re: Default Sizers, First Draft (was Re: [wxPython-users]

[Michael Hipp]

> From: "Don Dwiggins" <ddwiggins at advpubtech.com>
> Thinking out loud:
> 
> 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.

A good train of thought, but I always find myself thinking in terms of "I want the controls on this panel to have this taborder", so there is some level at which the problem has an optimal solution, so to speak.

>  There'd always be a default tab order in a top-level 
> frame, of course, but it will likely not be what a conscientious designer 
> wants.  (Or maybe not -- no designer-specified tab order, no effect when the 
> tab key is pressed.)  Perhaps a "linked list" mechanism would be a good way 
> to specify tab ordering: 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 hadn't thought about independent tab groups, but can see where they might be needed.

But... I think taborder ought to be a single property of something. If taborder is a property of every control, then to get a truly custom taborder you end up with a list of calls like this:

    ctrl1.SetTabPrev(...)
    ctrl1.SetTabNext(...)
    ctrl2.SetTabPrev(...)
    ctrl2.SetTabNext(...)

On a panel with lots of controls this would start to look amateurish. Much simplier to say:

   panel.SetTabOrder((ctrl1, ctrl2,))

Or, on the "independent tab groups" train of thought:

  panel.SetTabOrder(((ctrl1, ctrl2,),(ctrl3, ctrl4)))

Ug, looks like Lisp :-)

> As for how many sizer types are needed, I'd say 2: the BoxSizer (with 
> horizontal/vertical organization) and 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.

I think some form of grid-based sizer is the only way to go. It's the most abstracted solution. Maybe it could have a dual-personality API, to not only allow:

  sz.Add(ctrl, (0,0), (1,1))

But also:

  sz.Add(ctrl, wx.HORIZ)

Where this just puts them in a row. (That idea obviously would need some work.)

> 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).

I agree it's an oddball, but an indispensable one. Grouping controls with a static box is a necessity. And having those controls contained in a sizer that shadows the static box seems like the obvious solution. Or maybe if there were just a simple call to "Add()" a sizer to a static box. I've always thought the static box concept in wx was a bit odd as it seems like it ought to be a container.

Michael