From: Alan Gutierrez (alan-boost_at_[hidden])
Date: 2004-12-30 15:07:57
* David Abrahams <dave_at_[hidden]> [2004-12-30 14:53]:
> Reece Dunn wrote:
> > David Abrahams wrote:
> >> Yeah, geez. Single-rooted hierarchies of diverse functionality with a
> >> root class called "object" were discredited long ago, weren't they?
> > I am not suggesting a single-rooted heirarchy for *all* the classes as
> > that would be stupid. MFC does it to support their own version of RTTI,
> > memory leak tracking, etc. Java does it because it doesn't have
> > templates. .NET has it because it treats every object as a COM object.
> Python does it too. It's not neccessarily wrong for other languages;
> just C++.
> > The heirarchy above is for a UI object, where a UI object has
> > moving/positioning and event handling integral to it. Consider:
> > How do you intend on writing *UI objects* - frames, widgets, layout
> > managers, etc. - that can interact with each other, be moved and process
> > events correctly without sharing a common *ui::object* base? Here, I was
> > using the namespace as part of the name to denote the role that the
> > class plays, not that it is a monolithic uberclass.
> A layout manager that can be moved?? Maybe you have something else in
> mind, but I understand a layout manager to be a supplier of logic with
> no graphical representation.
That's the distinction I'm trying to make between renderers and
Reece is discussion a form/frame renderer. The strategy there is
to use a tree of nested boxes.
Yuumight have a splitter layout containing a NS/EW layout,
containing a grid layout (not a grid renderer, but an object
that arranges more objects in a fixed grid), in the grid layout
you have a list box, it has list items, etc.
When the splitter is moved, it changes shape and calls the
ES/EW layout, which changes shape and calls the grid layout,
which changes shape and calls the list box, which changes shape
and calls the list items, which change shape and call...
Java AWT, Swing, Delphi all use the term Layout to describe
these boxes of boxes.
A grid layout is an row/column layout of from controls, it
doesn't provied for resizing, sorting, ranges.
A flow layout lays out controls left to right, but it doesn't
layout text, paragraphs, columns, etc.
In this strategy, you are choosing to use memory to model each
axis-aligned bounding box as an actual object.
This is why I call it the *form* rendering strategy, and draw
distinctions between the *grid*, *document*, and *canvas*
That is why I'm talking about rendering, to make the distiction
between this simple, but inscalable strategy, and other, more
scaleable rendering strategies. There is a place for the *form*
strategy, but I don't think it is a foundation for all
rendering. Especially not in a generic programming language.
-- Alan Gutierrez
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk