From: E. Gladyshev (eegg_at_[hidden])
Date: 2004-12-29 15:22:19
Reece Dunn wrote:
> Hi All,
>
> We have different people with different needs and ideas as to what
> constitutes a UI system. The general concensus is that the resulting
> library should be designed independant of any target implementation and
> should support general platforms such as text-based systems. It is also
> advisable to allow interaction with a target platform to allow for
> platform-specific user code if required.
>
> There are several layers to a (G)UI library:
> [1] The platform independant layer.
> [2] The geometry layer - unit type, point, size, rect.
> [3] The base graphics layer - fonts, canvas, pens, images, etc.
> [4] The event handling layer - event loop, events, event handlers.
> [5] The UI object layer - frames, forms, widgets, lightweight objects,
> etc.
>
> Each of these layers is conceptually independant, but builds on top of
> the other. Should there be a separate library for each of these layers
> (Boost.Platform, Boost.Geometry, Boost.Graphics, Boost.Events and
> Boost.UIObject)?
>
> The design for the UI object layer must be able to support:
> * native-based UI objects that are dynamically constructed.
> * native-based UI objects taken from pre-built elements, e.g. objects
> on a form.
> * lightweight UI objects that are not native-based.
> * custom drawn native-based UI objects (either dynamically constructed
> or from pre-constructed objects), in essence a hybrid of native-based
> and lightweight UI objects.
>
> 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::form
> ui::main_frame
> ui::popup
> ...
> ui::widget
> ui::textfield
> ui::textarea
> ui::button
> ui::grid
> ui::table
> ...
> ui::layout_manager
> ui::flow_layout
> ...
Oh boy, it looks like another MFC to me.
Such single object derived hierarchies
usually don't work well. They are hardly
scalable.
Eugene