[boost] Re: [gui] Concerning Scope (Was: thoughts on a GUI component library)

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-12-28 10:50:56

Dave Harris wrote:
> In-Reply-To: <20041224050911.GA9037_at_[hidden]>
> alan-boost_at_[hidden] (Alan Gutierrez) wrote (abridged):
> 
>>>I'm a bit concerned about the scope of this boost project. Our 
>>>drawing framework is pretty huge.
>>
>>    This is an important discussion to have sooner than later.
>>
>>    1) Is a GUI project a bad idea?
>>
>>    2) Is Boost the right place for the a GUI project?
> 
> Supposing "yes" to both, that still leaves the question of scope. Possibly 
> a "GUI" could just mean a high-level windowing system, and not a graphics 
> drawing system. There is a lot to do just managing a tree of rectangles 
> and dispatching events to and through them. The windowing system should 
> arguably not care about the contents of the rectangles.

This is the approach that I am using by placing the focus on a native 
implementation.

> It seems to me that adding a graphics system, with pens and brushes and 
> polygons and text and bitmaps and wotnot, makes the project much bigger. 
> Which isn't to say we shouldn't do it, and do all of it, but perhaps it is 
> worth dividing it up into chunks or layers that are more or less 
> independent. If that is possible.

The main question is what to do when the two overlap. This can occur:
1.  When performing size calculations, such as working out the minimum 
size for a button.
2.  When defining the drawing events (i.e. specifying the canvas).
3.  When placing bitmaps/images in widgets such as buttons.
4.  When performing metric type conversions for a specific device.

I intend to keep the level of overlap to a minimum, but there are areas 
where it is impossible to prevent that overlap. For me, there are 4 
parts to a Boost.GUI library:
1.  The core library - platform independance and general types;
2.  The component library - event management, components/widgets, frames 
and forms, layout managers, etc.;
3.  The graphics core library - device and canvas, pens, fonts, brushes, 
etc.;
4.  The high-level graphics library - lines, polygons, circles, etc.

>>    I believe the time is ripe for a small, light-weight, XML + CSS
>>    renderer to attack the new surge of RSS content on the web.
> 
> OK. Perhaps my issue is that when I think of "GUI" I don't immediately 
> translate that into "XML + CSS".

The XUL (XML+CSS) look of Firefox/Thunderbird is one type of widget 
layout construction. Having a simple set of widgets, layout managers and 
frame types allows for an XUL-style extension, but XUL should not be 
specific to the Boost.GUI library.

XUL is a type of Form binding in that there is an XML description of the 
layout. This is complicated with the CSS because a CSS renderer is 
required, and the components need to be hand crafted to support the CSS 
processing. In order to do this, a large code base would be required.

Regards,
Reece