* Reece Dunn <msclrhd@hotmail.com> [2004-12-26 05:57]:
Alan Gutierrez wrote:
* Alan Gutierrez <alan-boost@engrm.com> [2004-12-25 07:50]:
* Reece Dunn <msclrhd@hotmail.com> [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. Applications: 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. *or* 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 cells. 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. Applications: 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.
Agreed.
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. Applications: 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;
Size. 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 event. 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. http://www.section508.gov/index.cfm http://bobby.watchfire.com/bobby/html/en/index.jsp http://www.w3.org/TR/WAI-WEBCONTENT/ http://java.sun.com/docs/books/tutorial/uiswing/misc/access.html 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@engrm.com