Boost logo

Boost :

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-12-24 05:45:56

Alan Gutierrez wrote:
> The OS Direction
> I'm looking over wxWindows. I'd like to avoid this sort of
> thing, yet another wrapper library.

It seems to be designed around Win32 and OS/2. Likewise, QT uses a
special preprocessing stage to handle signals/slots, which should also
be avoided. I aim to write a comprehensive comparison as part of my
library docs.

> A Taxonomy
> - The Dialog
> A collection of widgets, gathered together in a window that
> usually of a fixed size, usually presented to the user in a
> modal state. Hence the term dialog, indicating a back and forth
> between the user and the application.

I think dialog is the incorrect abstraction. In Windows, a dialog is a
pre-built frame that is identified by a resource ID. It constructs the
components based on the layout design in that resource. In MacOS, you
have a NIB file that describes a frame.

In general, you have the concept of a form: a form has a structure
specified by a resource file via an ID. This is mapped to the
OS-specific concept.

I have not yet added support for forms in my Boost.GUI library, but this
is something I intend on adding.

> - The Grid

A grid is an example of a layout manager. Generic support should be
added for layout managers and allow you to add managers such as
grid-layouts. Another layout is a flow layout, for example, adding
command buttons and placing them at the bottom-left of the frame along
the x-axis. I have a working implementation in the latest code and
intend to merge the new code into the sandbox.

> - The Document
> Text with a flow direction, broken by whitespace and
> hyphenation, along with imagry, and object, grouped by blocks,
> gathered into columns and tables.

What about graphics applications? You can have a graphical document/view
model with lines, polygons, ellipses, etc. Also, what about PDF documents?

It should be possible to support the document/view architecture, but not
exclusively like MFC does.

> - The Canvas
> Canvas applications include illustration, diagraming, charting.

I think the canvas abstraction should be used in a more general sense as
part of the graphics part of the library. It should have a low level
(pens, brushes, fonts, or whatever abstraction is chosen) with high
level objects (e.g. vector graphics objects such as ellipses).

Doing this would allow you to write turtle graphics applications with
the low level objects and an SVG renderer using the high level objects.

> - An Example
> A contemporary personal finance program uses The Dialog to set
> preferences and to open files, The Grid to display a check
> register for editing, The Document to display a nicely formatted
> balance sheet and a hyperlinked start page, and The Canvas to
> render a pie chart of spending by category.
> What did I miss?

What about a table? For example the JTable/TableModel in Java Swing. I
personally like this and have a version written using the sandbox
version of my library in Windows. I intend to port it over to the new
version and add it into the available components.

You could use the table in the finance program to view the financial
transactions and have a flow layout for the command buttons at the
bottom (new transaction, view/edit transaction, save transactions, load

There are other controls/designs such as tabs, e.g. editing multiple

What about property sheets (form collection)? How do you switch between
the forms in a form collection? Do you use tabs (e.g. property sheets),
lists (e.g. Mozilla Thunderbird options), trees?


Boost list run by bdawes at, gregod at, cpdaniel at, john at