[GUI] Dynamic ... something

[John Meacham]

Absolute positioning is quite unsuitable for a portable GUI library.
fonts are different sizes, widgets will be drawn differently, it will
just encourage programs which look bad on systems they were not
designed. not that that type of layout should not be provided, it can
come in handy, but it should not be the encouraged way to do things
unless you are writing a new portable layout algorithm, as it would
require extensive querying of the exact properties of every widget used
to make sure your layout looks good across platforms.

As a useful tidbit, I was able to implement full gtk hbox and vbox
layout algorithms in about 30 lines of Haskell. I think something like
them would be a good middle-ground common layout algorithm which could
be easily implemented on platforms that don't have it (on the Haskell
side of things) and is powerful enough to express most layouts people
want that will rescale and deal with differing sized widgets well.

        John



On Thu, Apr 10, 2003 at 10:29:41AM +0100, Alastair Reid wrote:
> 
> Glynn Clements <glynn.clements@virgin.net> writes:
> > different GUI APIs have radically different approaches to layout [...]
> >
> > Win32 takes the simplistic approach; each widget has a specified
> > position and size. The Xt approach is more involved. It has an
> > open-ended set of container classes (subclasses of Composite), each
> > of which is responsible for laying out its children. [...]
> > The most common Motif container classes are XmRowColumn [(which lays
> > out its children in rows/columns; menu bars and menus use this) and
> > XmForm (a more generic class, which allows each widget to specify
> > its position relative to its siblings or to the parent).
> 
> It sounds like all GUI APIs provide absolute positioning and may
> provide automatic layout.
> 
> So, unfortunate and limited as using absolute positioning is, I
> suggest that the core design should provide that as the base-level,
> portable, API.  This will be easy to implement and let us move
> forward.  
> 
> We can then experiment with ways of implementing our own container
> classes in Haskell (for those platforms that lack them) and of making
> the different styles of container class behave in a consistent way.
> If it turns out that the best of the automatic layout APIs in common
> use can be simulated on all platforms, we can then go ahead and add
> that to the portable specification.
> 
> (Also, people can play with their own layout mechanisms and algorithms
> if we give them the right base to build on.  e.g., I think that TeX's
> layout mechanism (e.g., 2\vfill + \vfil + 10pt) would be cool to use
> for laying out windows.  I may be wrong but it'd be fun to play with
> it.)

-- 
---------------------------------------------------------------------------
John Meacham - California Institute of Technology, Alum. - john@foo.net
---------------------------------------------------------------------------