Re: [boost] Re: [gui] GUI Taxonomy

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
    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_at_[hidden]