[boost] Re: [gui] The Big Picture

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-12-30 03:25:51

David Abrahams wrote:
> Alan Gutierrez wrote:
>>* Reece Dunn <msclrhd_at_[hidden]> [2004-12-29 14:39]:
>>
>>>All of these UI object forms need to be supported, including bindings to 
>>>different platforms/APIs. I see the basic UI object heirarchy as:
>>>
>>>   ui::object
>>>      ui::frame
>>>      ui::widget
>>>      ui::layout_manager
>>>
>>>Here, I want to keep the UI object heirarchy as simple as possible. That 
>>>is, the heirarchy is not dependant on platform specifics, but the UI 
>>>object group to which the object belongs.
>>
>>    I'd steer clear of an object heirarchy. The requirements you put
>>    forward indicate that a hierarchy is the wrong abstaction. I
>>    don't see why a main_frame has to be a decendant of the same root
>>    object as a layout_manager.
> 
> 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.

The heirarchy above is for a UI object, where a UI object has 
moving/positioning and event handling integral to it. Consider:

class mainfrm: public ui::main_frame
{
    ui::flow_layout buttons;
    ui::table       data_view;
    public:
       void update_layout( const geom::rect & area )
       {
          geom::size bs = buttons.get_minimum_size();
          geom::size ds = data_view.get_minimum_size();
          bs.move( ... );
          ds.move( ... );
       }
};

void gui_main()
{
    mainfrm app( "Demo" );
    app.move( 100, 100, 300, 500 );
}

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.

Note that I haven't suggested having ev::event_loop, geom::metric, 
geom::point, graphics::device, graphics::font, graphics::canvas, etc. 
sharing a common base class because they do not fit into what 
constitutes a *UI object*. Perhapse the high-level vector graphics 
objects (vector::line, vector::ellipse, etc.) will, but that is only a 
consideration.

Regards,
Reece