|
|
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.
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_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk