Re: [boost] Re: [gui] The Big Picture

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.

    David,

    That's the distinction I'm trying to make between renderers and
    layouts.
    
    Reece is discussion a form/frame renderer. The strategy there is
    to use a tree of nested boxes.

    Example:
    
    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*
    rendering strategies.

    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