[boost] Re: [gui] GUI Taxonomy

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-12-26 11:13:00

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

To me, a rendering strategy is something that is implemented by the 
application using the graphics framework. This covers your Document and 
Canvas strategies that target two different types of rendering model 
(one text-based documents, the other, graphical content).

When you look at what a form is, you write a resource that describes the 
window and controls it has and get the OS to construct the window from 
that resource. In Cocoa/Carbon, that is a NIB file and in Windows it is 
a Dialog resource. These are different from a rendering strategy because 
they interact with the operating system, providing a top-level UI frame.

I define a widget/component as a *UI object* that is usually provided by 
the OS. Thus, a table is a widget in Windows (a report-view ListView 
control). A grid is a tricky area because it is not provided by the OS, 
but it is a component because it provides a user interface to specific data.

>     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.

So is the form.

>     I view a Form as a content rendering and event strategy.

I have the basic structure:
    layout::layout
       component
          frame
          widget
       layout::flow

where layout contains the basic interface to get minimum size and update 
layout; component adds OS binding and event handling; frame provides a 
component that has a content area (drawn to using a rendering strategy); 
and widget provides data-based components that are placed on a frame.

>>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.

But the Form and Grid are not drawn by the application and are connected 
to the OS.

>     My point exactly. These are all documents. Documents are
>     omnipresent. (I've never spoken of retrictions.)

Okay. I see where you are coming from with this.

>     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.

This is what I am trying to do as well.

>>>   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.

What I meant was what I have described above.

>     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.

Which is what I am doing with table/grid + cell-provider. The 
cell-provider is the data model. What I am saying is that there is often 
OS support for this model and should be used when applicable, thus it is 
a widget.

>     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. 

This is like what Andy Little has said about treating graphics objects 
as lightweight components (possibly with events).

With the text object you describe, do you clip the text? Do you provide 
scolling? Do you support editing? What about undo? What starts out as a 
simple object becomes fairly complex.

Providing a font object, allowing you to draw text to a canvas using the 
font will allow you to implement the above to suit your applications 
needs. Also, providing a separate scrolling class will allow you to have 
scrollable content.

>>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.

A rendering model (how something is drawn) does not encompass things 
like events and OS interaction.

>>*  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 think that this is not the right approach. You should only roll your 
own controls when that control isn't supported by the target OS. The 
Win32 GDI and Win32 controls/common controls are different things.

I need more time to think about how to provide an independant 
abstraction for graphical elements, since I have been mainly focussed on UI.

>     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.

Implementing a check box in Win32 as a custom control, how do you handle 
things like tabstops, using spacebar to check/uncheck the checkbox, 
provide XP theme support and a whole host of other things provided by 
the OS?

>     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.

The question is whether you want a consistent x-platform L&F or a native 
platform L&F. I think you want a consistent L&F as default, whereas I 
want a native L&F as default.

I want to provide the ability to write lightweight components, native 
components and custom rendering for native components. Lightweight 
components does not mean having a lightweight button (you could write 
one if you want), but means a component that does not consume OS 
resources (e.g. layout managers).

>     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.

But the OS provides that native L&F. I don't want to go the Java route 
of not providing native component intergration. I agree that 
accessability needs to be addressed in some form or another, but by 
using native components, you get a lot of that accessability for you 
provided by the OS.

Regards,
Reece