From: Alan Gutierrez (alan-boost_at_[hidden])
Date: 2004-12-24 09:02:22
* Reece Dunn <msclrhd_at_[hidden]> [2004-12-24 06:51]:
> 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.
I'm not talking about a particular implementation, of corse, but
a UI concept, which let's call The Form, but I didn't want to
get it confused with XHTML forms, XForms, or PDF forms, which
are more in line with The Document below.
So, I called it The Dialog, but you're right, there is much more
to it, there are applications like Visual Basic that are all
about creating Forms, editing Forms, and validating Forms.
Still, I think the constraints on this sort of thing are
generally that the developer is choosing and arranging a fixed
number of controls.
If there is a variable number of controls, those are placed in a
special form control like a tree, grid, or drop down control.
I'm imagining Visual Basic, Power Builder, and Delphi, and
thinking of the layout managers in Swing.
> > - 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.
A grid is more than a layout manager. It has to scroll. I has to
provide for selection of cells, which a layout manager does not
have to do. It has to be able to add controls, perhaps as a new
row of controls, perhaps as a new cell in a spreadsheet.
When I think of a grid application, I'm thinking of the problem
address by JTable/TableModel, which I'll get back to below..
> > - 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.
I'm not using the term document in terms of document/view, and
I'm not talking about graphics documents.
In this taxonomy, graphics applications are falling under the
realm of a canvas-oriented application.
I'm talking about human language document oriented applications
like web browsers, word processors, and reporting.
This component of an application is exemplified by the browser
controls that are now a *staple* of GUI component libraries.
Again, I am not talking about the document/view architecture. I
am talking about XHTML + CSS, XForms, PDF Forms, rich text
editing, hyperlinking, man pages, etc.
> > - 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.
I should have noted, I'm not trying to suggest an architecture.
I'm talking about the different sorts of UIs out there. There is
obviously going to be a an object that reprensts a drawing
surface, but I'm not addressing that here.
Again, I'm simply trying to layout the different types of
application. When I open up Visio, I see this big, blank Canvas,
along with a palette of graphic shapes.
This is very different application than when I open up Excel,
which is a big Grid, or open up Firefox, which is a Document, or
open up System Preferences, which is a bunch of Forms.
I agree that the design that is being sorted out, for points,
and shapes, is part of the graphics library, and is vital, and
that the right design is important for simplifying the
creatation Canvas like application.
Note that graphics might not really come into play, say on a
character console, where one might still want to mode The
Document (like man pages, or lynx) or The Form. It would still
be nice to be able to use the idioms UI library to assemble a
console based Form UI.
Also, most UI libraries provide special support for Forms, as in
dialog resources, or layout managers. Many provide a Grid
library, that let's a developer compose a table using widgets.
The Document application becomes simplier, as developers choose
to embed KHTML, Mozilla, or IE, or use one of those browsers as
The Canvas is usually left as an exercise for the application
developer, but with generic programming, I think that C++ can do
> > - 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.
I think a table is an example of The Grid. I'd would called The
Grid, The Table, but I also think a spread sheet is The Grid,
and I don't think of a spread sheet as a table.
I think the JTable/TableModel is a very valuable, and effective
abstraction. The Swing developers reocognized that there are
great many business applications that display information in
tables, and provided a good, general-purpose table library.
It is more than a layout control, because it needs to respond to
scrolling and selection, the columns can be reordered and
resized, rows and columns hidden or deleted. It is a very
I think a new GUI library should good general-purpose document
library, which is why I'm putting forward this taxonomy. I'd
like to make sure that a GUI library is designed to address the
expectations of application developers, and the lack of a rich
text library is going to be felt.
> 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
Yeah, we are saying the same thing, then. I chose a different name.
So, to clarify, I'm not saying, oh, oh, let's have a grid
control! Rather, that in the world of 2d UI, a Grid, or Table,
is a canonical representation of tabular data, and that
developers are going expect a certian set of facilities to
support their development of tabluar, or grid UIs.
> 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?
Mozilla Thunderbird options are implemented using XUL, and the
trees in Mozilla Thuderbirds are implemented using The Document
(XML + CSS) so when I look at the Advanced pane I see what is
very obviously The Document used to arrange controls with
When I look at the General pane I see The Form with controls
organized into groups.
Otherwise, tabs, SDI, MDI, toolbars, menus, docking, drag and
drop, the clipboard, might be outside of this taxonomy, since
they are framing around an applicatoin, and not an application
All of the above canoncial forms use windows, and will most
likely use menus and cut and paste.
The Canvas in this taxonomy, is not the library of 2d
privimitives, but a kind of application, like Illustrator,
Rational Rose, AudoCad.
Providing window dressing that allows a developer to organize
their Forms, Grids, Documents, or Canvases into tabs, or have a
Form, Grid, Document, and Canvas view of relational database
(record entry, tabular entry, reports, and ER diagrams, say) is
on the other end of the spectrum from the 2d library of
primitives. Here we are talking about windowing, and MV[CP]
In fact, the 2d graphics primitives, on the one hand, and thier
framing on the other, are both the areas of integration, where
the GUI library abstraction ends, and the interation with the
underlying operating system begins.
The Revised Taxonomy
The Form, The Grid, The Document, & The Canvas.
-- Alan Gutierrez - alan_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk