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