Dave Harris wrote:
In-Reply-To: <20041224050911.GA9037@maribor.izzy.net> alan-boost@engrm.com (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