* Reece Dunn <msclrhd@hotmail.com> [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 a platform. The Canvas is usually left as an exercise for the application developer, but with generic programming, I think that C++ can do better.
- 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 speciliazed concept. 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 transactions).
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 documents.
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 collapable paragraphs. 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 in themselves. 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] architectures. 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@engrm.com