RE: [boost] Re: GUI sublanguage ?

From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2003-08-06 19:28:21

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> On Behalf Of Joel de Guzman
> Sent: Wednesday, August 06, 2003 5:51 PM
> To: Boost mailing list
> Subject: Re: [boost] Re: GUI sublanguage ?
> 
> Brock Peabody <brock.peabody_at_[hidden]> wrote:
> 
> >> Have you invented universal algorithm for window size/position ?
> >
> > It works surprisingly well.  I know I described it in detail in an
> > earlier post, I can sum it up again if you like.  It works well
> > especially if you need complete resizability.
> 
> Please do. I've lost track of the thread and I want to catch up.

When we first started doing GUIs, we put things exactly where we wanted
them :)  We would either disallow or ignore resizing.  This is the type
of sizing logic that is promoted by RAD tools.  Eventually you find that
you can't ignore the issue.

Our first attempt at a sizing 'algorithm' was that everything in a
window was sized proportionally as the window grew and expanded.  This
led to cartoonish screens at large sizes.

The reason is that some controls benefit from increased size and others
don't.  More specifically, each type of control usually has a minimum
and maximum desired size for each dimension (sometimes the maximum is
unlimited).  Examples:

static text - fixed size horizontally and vertically

line edit - fixed size vertically.  Minimum of one character
horizontally and unlimited size horizontally.

masked edit - both horizontal and vertical sizes can be fixed based on
the mask.

The earliest version of this library was concerned strictly with laying
out controls.

Each layout composition function returns an object that can be
positioned in a rectangle, and can tell you what its desired size is for
each dimension.  If you pass a plain window to one it will 'wrap' it for
you.  The objects returned by the composition functions can in turn be
passed to other composition functions (or themselves recursively).

row(x, x1, ... xn) - positions its components one after another
horizontally.  Space is allocated first for 'minimum sizes'.  Left over
space is split evenly among components with no maximum, or with maximums
that are greater than their minimums.

column(y, y1, ... yn) - same as row but vertically

grid<number of columns>(c0, c1, ... cn) - sometimes it is important for
the elements in subsequent rows to 'line up'.  You can use the grid
function impose more strict sizing than is possible with combinations of
rows and columns.

I realize that this scheme won't solve all the world's problems, but it
comes close :)  You can imagine that one could come up with more
composition functions, I just haven't needed any yet.

This positioning library began evolving into a complete GUI library when
I realized that I could allow the inline definition of static text
controls, and get rid of them completely:

   row ("label: ", some_control);

After that I wanted to get rid of more controls and define them all
inline.

I hope I explained that well.  My communication skills could be improved
:)

Brock