Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk