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 transactions). 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? Regards, Reece