[wx-dev] Ideas for Future wxWidgets

[Jorgen Bodde]

Hi All,

That is just what I meant. The sizer system should be that intuitive
that people who use them a lot but with intervals should not have to
revert to the docs for the order of arguments, what flags should be
set, if a lot is done for you by default (but can be changed if
needed) it should be easier to use them,

> BTW, you can already write an "HTML layout" for wx dialogs by using wxHtmlWindow, but not many people take that > approach.

My html'ish example was more a concept, I know I can use wxHtmlWindow
but the point I was trying to make is that a a GUI layout builder
should intelligently apply sizers without the user knowing too much
about it. By specifying it row by row and let the system figure out
what sizer type is needed, you already take away the burden for the
user.

You can for example combine the Delphi way of making a GUI with the
wxSizers, by specifying anchors. If you tell the system that an edit
ctrl has anchors left and right, it means it will expand horizontally.
An anchor right means align right, etc.

But time will tell. I am happy to think along about new sizer
concepts, but I don't think we can reduce the code footprint that much
without resorting to some kind of layout shift  which is an
intermediate solution between the code needed to be generated (or
executed while parsing) .. If I look at the manual way of creating a
layout (not GUI generated) solutions there are three ways to go:

At one end, specifying it all in C++ code means:
1. A hierarchical solution
2. No readability but a lot of flexibility
3. Inherent complexity for all the flags needed
4. Too tightly coupled with the sizer system

Using a layout specification e.g. as a string to be parsed means:
1. A lot of intermediate actions done for you
2. Less flexibility
3. Less complexity, to some extent readability
4. Loosely or not coupled to the sizer system

Using something like XRC only means:
1. Lot of flexibility
2. Too much overhead to write by hand
3. Too tightly coupled with the actual sizers
4. Great for GUI designers

Which way we might choose for the sizer system in the future, you will
always fall in one of the three above categories. Making it more human
readable using C++ code only, is nearly impossible

A nice attempt might be using the shift operator:

wxLayout l;

l << "A Label" << new wxButton( ... ) << wxLayout::BR;
l << "Select a path" << wxLayout::BR
l << wxLayoutSpec(new wxTextCtrl( ... ), anchor="left;right") << new
wxButton(...) << wxLayout::BR;

Specifying it like this, it looks for the user the controls are alligned like;

 [Label]  [Button ]
 [Label]
 [TextCtrl]  [Button]

But the layout class actually produces for you:

VSizer
--- HSizer
------ Label
------ Button
--- Label
--- HSizer
------ TextCtrl
------ Button

Which already is a step in the good direction as you don't loose which
controls are horizontal, and by applying breaks in the shift operator
the layout class can intelligently push previous content in a HSizer
and shift to a VSizer. The user has not much to do with specifying
flags, only when needed, using something like wxLayoutSpec() as a
wrapper class.

Just my two cents.
- Jorgen