Boost logo

Boost :

From: Alan Gutierrez (alan-boost_at_[hidden])
Date: 2004-12-26 09:51:06

* Reece Dunn <msclrhd_at_[hidden]> [2004-12-26 05:57]:
> Alan Gutierrez wrote:
> >* Alan Gutierrez <alan-boost_at_[hidden]> [2004-12-25 07:50]:
> >
> >>* Reece Dunn <msclrhd_at_[hidden]> [2004-12-25 07:03]:
> >>
> >>>Alan Gutierrez wrote:
> >>>
> >>>> The Revised Taxonomy
> >>>>
> >>>> The Form, The Grid, The Document, & The Canvas.
> >>
> >>>I think that trying to work out the taxonomy of user interfaces is the
> >>>wrong way to go. In general, it is not clear how these break down.
> >>
> >> Really?
> >>
> >>>For example, an application will usually have a main interface frame,
> >>>such as the web browser. In this case the taxonomy is the Document to
> >>>use your terminology. The application may also provide a set of options
> >>>that the user can configure, which is The Form.
> >>
> >> Perfect break down.

> Let me clarify.

    I've thought about it some more, and FGDC is a set of rendering
    strategies. That is my taxonomy.

> I view the grid and table as a specific data-bound
> components/widgets that makes requests for data, i.e. row/column
> information and cell queries. This will fit in with other advanced
> UI components such as the tree.

> The way that I am approaching components is to define a specific
> data+event relationship, for example:
> * textfield = std::string text; event::ondatachanged();
> * push-button = const std::string title; event::onpressed();
> * button-group = event::onselectionchanged( long sel );
> * calendar = boost::gregorian::date date; event::ondatachanged();

> This allows you to bind specific actions to a data component and to
> query its content.

    A rendering and event strategy.

> I view a form as a specific type of frame. A frame is a component that
> supports a frame and will contain other components. Examples include:

    A rendering and event strategy.

> * main-frame - the top-level application frame with a close
> button, menu, etc.
> * form - a frame that has a layout specified by an external resource
> located by an ID, e.g. Dialogs in Windows and NIBs in Mac.
> * popup - a popup frame that may not have border decoration. This is
> used, for example, to host controls beneath a button
> when the button is pressed (such as a calendar).

    I see the Frame as part of the windowing system. It organized
    content areas. It might have tabs and, spliters. It might be
    very spare as on PalmOS. It is the work that is supposed to be
    done for you by the OS or GUI library.

    I view a Form as a content rendering and event strategy.
        Rendering Strategy:
            Simplyfy rendering and event routing by arranging a
            fixed set of user input "components" onto a client area
            divided into rectangular regions.

            The division by region can be done through a composition
            of layout strategies, or the controls can be positioned
            at fixed locations on a client area of fixed size.

            Rendering is performed by rendering borderes and asking
            each "component" to render itself.

        Event Strategy:

            All "components" are on the same z-axis. All
            "components" are rectangular. Mouse events simplified by
            rectangular shape of regions and controls. Each
            "component" responds to OS events individually through
            some well known behavior.


            Dozens of Form Designers, Oracle Forms, Visual Basic,
            Power Builder, PalmOS.
        UI Usages:

            Application preferences, file selection, database record
            entry, any place where a set of not terribly variable
            properties are edited.

            Can contian more complicated rederers.

        Minimal Library Needs:
            Axis-aligned boxes. "Component" impelementations.

            Handles to OS generated resources.

    I view the Grid as rendering and event strategy.

        Rendering Strategy:

            Simplyfy rendering and event routing by arranging a
            fixed set of user input "components" onto a client area
            divided into rows and columns.

            User is able to resize rows and columns. Overflowing
            text within cells is clipped for overlays the adajcent

            As information is added to a document, it is rendered as
            new rows in the grid.

            Render text with in "cell" or to cell has input focus,
            delegate rendering to an input "component".

            Rendering of cells can be buffered. Insertion of cells
            can be rendered from the buffered images. Cells off
            screen need not be rendered. Cell off screen can be
            rendered in advnace of their scrolling into view.

        Event Strategy:

            All components and cells on same z-axis. Mouse events
            mapped to a row and column. A cell responds to an event
            by displaying an input "component".

            Additionally a grid provides logic for the selection of
            ranges of cells.


            Excel, Access, SPSS, SAS.

        UI Usages:

            Database records, spreadsheets, check registers, e-mail
            inbox listings, or any other form of tabular data.

            Grouping of Forms, Documents, or Canvases in repition to
            create a card listing.

            Implementation of tables within documents.

        Minimal Library Needs:

            Axis-aligned boxes. Fonts. Components. Scrolling.

    Forms are one way to render content. It is a very simple
    rendering strategy. Constraints are placed on the capabilities
    of the UI.
    The Grid is another content rendering strategy, that was
    designed to present structured content that is repetitive.

    Neither of these strategies are more or less worthy of
    implementation as framework that a Document or a Canvas.

> The Document and Canvas to me are specific renderers that are used
> to render content on a frames usable area via a graphics canvas.

    As are The Form and The Grid.

> We should not be restrictive on what type of renderers we allow,
> because you will need a different DOM if you are rendering HTML
> content (using the W3C DOM), a text editor (using a custom text
> DOM), a PDF document (using the PDF specification).

    My point exactly. These are all documents. Documents are
    omnipresent. (I've never spoken of retrictions.)
    The source of the data is immaterial. The Grid going to come
    from? The DOM is an abstraction that does not need to be bound
    to the renderer, any more than the a grid needs to be bound to
    a flat file.

> an SVG application (using either a custom representation, an array
> of high-level graphics objects or the W3C SVG DOM).
    An obvious application of vector graphics.
    Which is another point to consider. Is a form, grid or a
    document best defeined in terms of an advance vector grpahics
    library when most of them can be rendered as axis-aligned boxes?

> What I am trying to say is: provide the framework for rendering
> content and the interaction between the frame and the graphics
> canvas, then let the application writer construct the document
> model that they need.

    What I'm trying to explore is a set of core rendering
    strategies, and their needs, so that might provide an
    implementation that hits the 80 of 20, or faciliate its
    implementation. Not throw up our hands and say, that's the
    application arena, we cannot forsee.

> >> I'd say that the framing, tabs, splitters, and the like, are
> >> part of content area management. I'm intereseted in providing
> >> application developers with building blocks for the content
> >> area, and more than wrappers around common controls and graphics
> >> primatives.

> I am not suggesting a low-level wrapping around the various widgets.
> What I am suggesting is that we focus on the type of *data* that a
> widget supplies and support that in the widget implementation. This base
> data (e.g. std::string in a textfield) can be converted to the required
> type (e.g. a long) by the programmer when they write the application.

> If you require data binding, it should be easy to write this on top of
> the GUI framework, but data binding should be seen as an extension.


> > Maybe Taxonomy was too portentious. I don't want to get bogged
> > down defending a "Taxonomy", when I'm trying to learn bjam and
> > Boost.Build in the other window.
> >
> > Content building blocks, I'd like to have 'em.

> Sure, but isn't this what components/widgets are? I know that they don't
> fit in with providing HTML or PDF content, but this is
> application-specific data rendering.

    No. I don't see document rendering as widgerty. When it's done
    as a widget it falls flat. Widget is not the proper
    classification of the document. It is a rendering strategy.

    Swing recognised with with JTable/TableModel. That is wasn't
    just another widget for the widget stable, but a first class
    citizen. Something that requried special design. The the frames
    and the widgets in Swing were deisgned to accomodate use within
    the JTable/TableModel. It isn't a widget. It didn't just happen.
    JTable/TableModel was not possible in Java's AWT.

    It is an excellent architecture, and one worth repeating.

    Let's look now at the rendering strategies used and design the
    framework to accomdate rendering strategies? Why not make
    flowing text a similarly first class rendering engine?
    In this way the frames and widgets can be desinged to accomdate
    a flowed text rendering strategy, and that bulk you speak of can
    be shaved.

> There are commonly supported content renderers (simple text and
> rich text editors) that should be provided by the GUI library, but
> then you get to the issue of whether this is cross-platform and do
> you also supply HTML+CSS content?

    Let's get into it.

> > I'd like to talk about them. In addition to the dialog boxes,
> > the tabs and splitters, the graphics primititives, can a
> > Boost.GUI provide some robust strategies for the client area of
> > the application? This is really the discussion like like to have.

> This is really about content rendering models, document/view
> architecture, MVP architecture, etc.

    This is really about rendering models. Maybe about MVP. But, it
    is /really/ about rendering models.

    If you say: "provide the framework for rendering content and the
    interaction between the frame and the graphics canvas, then let
    the application writer construct the document model that they need."

    If say say this, you've drawn a boundery between a GUI library
    and the task of rendering. A boundry that deserves more scrutiny.
    What's is the 80/20 of the "document model model they need"?
    I say FGDC. I might be wrong, but I think it is important to
    say something, so that the UI library really does facilitate the
    task of rendering content.

    I'll do what I did above:

    I view the Document as a rendering and event strategy.

        Rendering Strategy:

            Simplify rendering and event routing by arranging the
            text in accordance with a time-worn, standard-specified,
            human understanding of the arrangement of text.

            User is able to enter data by placing caret on areas of
            document and typing or pasting. Adding text causes the
            document to "reflow".

            Alternatively, "components" may be placed within the
            document, arranged in accordnace with typesetting
            conventions. Input is thus delegated to a component.
            Rendering is performed accordance with the grouping of
            text into blocks. Rendered blocks of text can be
            buffered for redisplay or shifted during reflow. Blocks
            of text off screen need not be rendered. Blocks of text
            can be rendered in advance of their scrolling into view.

        Event Strategy:

            Blocks of text may or may not be on the same z-axis.

            Mouse events are directed to an object block of text
            or component over which they occur. They event is sent
            to the enclosing block (paragraph, column, page, etc.)
            until it reaches a root block representing the document.

            Any block (at developer discression) may accept the
            caret and text input.

            If a component is present in the document, events are
            delegated to the component, before the are forwarded up
            the block heirarchy.

            Additionally, the document provides logic for the
            selection of text.


            Word, XForms, Help, FireFox, IE, Safari, Reader, vi,
            PostScript, Eudora, Cyrstal Reports, and on and on.

        UI Usage:

            Tree controls, online help, hyperlinked start pages,
            wizzards, text editing, forms, RSS, e-mail, HTML,
            labels, call-outs, splash pages.

        Minimal Library Needs:

            Axis-aligned boxes. Fonts. Scrolling. Caret.

    As a rendering and event strategy, it is more complicated, but
    not much more complicated than The Grid.

> > Widgets + layouts hit a ceiling pretty quick.

> > I'm really impressed with Thuderbird and Firebird, where they've
> > used their XML + CSS renderer, the content renderer, to do
> > pretty much everything else, wigets, splitters, dialgos. I think
> > that shows a lot of forsight.

> There are a few issues with providing an XML+CSS layout renderer like
> Thunderbird/Firefox:

> * The implementation would require an XML and CSS parser as well as the
> ability to draw the content to the screen (to support the CSS
> side of the proposal) - this would make the resulting code base
> exceptionally large;
     It wouldn't require XML or CSS. The Mozillans have expressed
     regret that they bound their renderer to XML DOM. It would
     support stylized text, and text flow and layout, but the
     specification would come through a binding.

     I'd puruse the development of a document renderer. With it I'd
     develop a non-validating XML parser and CSS parser in Spirit. I
     believe there is some XML work in Spirit already for serialization.

     If more powerful XML work was needed, a library user could bind
     the document renderer to Xerces C++, or they could write their
     own binding, along the lines of your cell_provider.

> * Thunderbird/Firefox use this approach because of the nature of the
> application - they already have a very good XML+CSS parser and
> content renderer as part of the web browser;

    Regardless of the reason, it is a successful approach. T/F is
    cross-platform, i18n, and skinnable. It works. It is easy to
    script and extend.

> * Do we implement the renderer ourselves (expensive in terms of code
> size, effort and tracking down bugs) or use an external
> renderer like Geko (Mozilla) where we have licensing issues;

    A document rendering strategy for Boost would not have to
    support legacy HTML, which is a huge source of the Mozilla bug
    count. Nor would it have to support HTTP, FTP, SSL, or JavaScript.

    If you reduce that to flowing text layout, it is more
    complicated that a grid renderer, but not so complicated as a
    web browser.
    It could choose to support only a subset of document rendering
    initially, and might even be designed to degrade.
    I'd like to have the z-axis be a compile time design decision,
    for example. If you don't need it, compile it out. If you do
    need it, comiple in an implementation based a Canvas library.

> * How do you provide the UI, i.e. the event binding and event flow?
    Another reason for positing FGDC.
    The document, as specified by XML DOM has a very intuitive event
    model. The event is routed through a tree heirarchy that
    represents the structure of the document. If you click on a
    *bold* bit of text, the event is rounted first to the division
    representing the bold text, then to the enclosing paragraph,
    then to the column, then to the column. Any one of those objects
    might have an event handler.

    Event handling for documents has a well defined pattern to
    follow, the UI framework should accomdate that. If a mouse click
    lands on a document, the UI framework should delegate the event
    routing to the document renderer.

    It is the same with with the grid model, though. Somewhere their
    might be a universal event handler that want's to know the cell
    row and column, information that does not pertain to a raw mouse

    Different rendering strategies have a different view of events.

    Different rednering strategies route their events using
    different algorithms.

> * What about people who want/need/require native interoperability?
> * How do you use native controls to get a native L&F?

    With Carbon, I think you just use native controls.
    With Win32 GDI you roll your own controls.
    I'd use the document renderer to render the GDI text box
    replacement, and the canvas renderer to render the GDI check box
    replacement, because that's what the renderers are there for.

    It becomes the same question in /any/ of the overlay layouts.

    This is why I raised the question in another thread.
    If we crack that nut, then the development of x-platform
    rendering strategies is simple. Regardless of a document
    renderer, if we don't, then we've left a huge problem unsolved
    for the end user.

> * What about other issues inbuilt to an operating system?
> * How do you interact with screen readers for blind users?

    Well, I'm looking into it.

    As native L & F, this is what libraries are for. If you are not
    going to address accessibility in the framework, then you've
    left a huge problem unsolved for the end user.

> In my opinion, the Boost.GUI library should be as lean as possible, but
> provide the framework that allows for XML+CSS applications, skinned
> applications, etc.

    Fine. I'm rasing a discussion of content rendering to keep
    Boost.GUI as lean as possible.

    FGDC is about rendering strategies, what they require, and how a
    library can be designed to faciliate a lean, device specific
    implementation of these strategies.
    XUL succeeds as a framework, because the framework is developed
    in terms of a renderer, it works from the inside out.

    In closing.

    I see the Canvas as a rendering and event strategy, but one that
    goes beyond the need of most applications. It seems odd to build
    a lot of vector graphics into a drawing surface, when many
    UI applications will need axis-aligned boxes most of the time,
    and some won't need it at all. I see the Canvas as a rendering
    and event strategy that sits parallel to Forms, Grids, and
    Documents, not a foundation for Forms, Grids, or Documents.

Alan Gutierrez - alan_at_[hidden]

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