Boost logo

Boost :

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


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