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