[wx-dev] Ideas for Future wxWidgets

[Jorgen Bodde]

Also, if we are talking about future wxWidgets, the wxSizer way of
things really need to change. Especially the way the expanding and
propagating that expand flag to the main sizers. I can have a lower
level wxSizer that is set to expand, but it does nothing because I
need to tell 4 sizers up on the tree that they also need to expand. It
should be explicitly done for the user, because that expand flag
otherwise does not do much anyway.

Using wxWidgets / wxPython for a while, I always get stunned by the
complexity of writing a GUI by hand, while it does not need to be like
this. Maybe we need some intermediate XML layout specification that is
not as 1:1 towards sizers as XRC (which is simply an XML
representation of the layout, but very powerful), and not as difficult
as writing your sizer constructs by hand, but instead specifying it
like a HTML like structure which abstracts most of the sizer
specification / construction from the layout. Some string representing
the GUI that can be kept in the source code, but also external as file
with typical constructions like;

<label>Hello world</label><br/>
<Button>Press me</label>

Which is near HTML, and upon parsing will result in a VSIZER with a
label and a text. Specifying something like;

<label>Hello</label><button>Press Me</button>

Will result in a HSIZER with two elements in it. And something like:

<label>Path one</label><br/>
<edit name="text1" anchor="left;right" /><button>...</button><br/>

<label>Path two</label><br/>
<edit name="text2" anchor="left;right" /><button>...</button><br/>

Will display two expanding path edit boxes with a browse button and a
caption above it with the sizer structure:

-Vsizer
--- Label
--- HSizer
------ Edit
------ Button
--- Label
--- HSizer
------ Edit
------ Button

The way the sizers are determined is by investigating when a <br/>
occurs in the semi-HTML code. A lot is done implicitly for you, and
since it is almost HTML it is much more readable. If an intermediate
parser like this is there, then most of the typical dialogs can be
whipped up in no time and not much GUI-coding-by-hand is needed. A
while back I was thinking about this, but other projects kept me from
investigating this concept further.

Just my two cents. If you do a lot of stuff implicitly the developer
is not bothered that much with sizer layouts.

- Jorgen