The NGLayout views subsystem is designed to support arbitrary positioning, sizing and depth sorting of overlapping rectangles of content in a platform independent fashion. Most NGLayout rendering operations begin by "damaging" a portion of the area currently being displayed on an output device and then walking over a view tree in z depth order allowing each view to repair parts of the damaged area they occupy. Event handling within NGLayout also goes through the view system giving view objects the first opportunity to handle event processing (within each view, there is generally content represented by layout Frames that do most of the real event processing). View update operations can either happen in an offscreen buffer or directly on the output device depending on the complexity of the anticipated update. Timed refreshes also occur allowing many damage requests to be processed as a single update to the output device. In addition to representing specially positioned content, a view may also represent an underlying platform native window through it's association with the Widget subsystem. The Widgets can be used to represent application controls such as scrollbars and top level windows and content objects such as HTML form elements. See the Widgets documentation for further information.

Major Components

Currently, there are four different classes within the view system. Naturally, more can be added as deemed necessary:

• Basic View class responsible for positioning, sizing, painting and event handling as a container for underlying content. Currently, the "compositor," which is responsible for handling issues of transparent views when painting, also lives inside the base view class implementation. In order to allow new types of views to be created without the need for subclassing off of the base view, this code will most likely move into the ViewManager.

• Scrolling View which has private child views representing scrollbars and additional methods for handling the scrolling of an additional child view that the owner of the scrolling view can add to the scrolling view.

• View Manager which coordinates all operations done to/through the view hierarchy including:

  • child view insertion, removal and sorting.

  • event handling.

  • damage repair coordination.

  • view state changes (position, size, clip rect, z index, visibility)

• View Observer which allows an application to receive notification when changes occur involving a view. Currently, these are:

  • painting

  • event handling

  • on screen position change

1. View Manager.

Applications create views and then added them to the view hierarchy through the view manager. From that point on, the application requests that changes be made to views via the view manager. This allows the view manager to "do the right thing" when views are changed. Typically this means minimizing the damage repair area and frequency of updates. As mentioned previously, views are arranged in a hierarchy. The relationship of sibling views is maintained through either an absolute z index for each view, or above/below relative to another view. When the view hierarchy is traversed, views are encountered in top down order and from nearest z to furthest z.

This is the base view class and the one generally created by content that requires a view. Examples of such content are CSS positioned elements, Communicator 4 layers, objects that require Widgets such as form elements, etc. Since views are designed to act as containers for content, there is a link to that content which can be set and queried with the Get/SetClientData() methods.

In general, views hold state, but don't do much in terms of changing or manipulating other objects. That job is left to the view manager.

Child views are not clipped to the boundaries of their parent views unless a cliprect is specifically set on a view. A clip rect clips the content displayed by a view and any of it's children.

The view contains a "compositor" which processes the view tree at rendering time to optimally paint the damaged area. This involves determining if any of the views are "transparent" and then doing back-to-front/front-to-back view processing to repair the damage. Views currently have an opacity property that the compositor will use to alpha blend views together. This functionality will be moving into the view manager.

The scrolling view, which is used as the root level view for NGLayout documents, is essentially designed to act as a container which expects that it's size will be smaller than the views that it contains. It also assumes that the application will want to be able to scroll over the area that is "inside" of it. As such it will automatically sprout scrollbars when the scrolling view is too small to display all of it's contents. It has additional APIs over the standard view to allow the application to get and set the offset into the visible content area and to recompute the size of the scrollbar thumb and position based on the sizes of the objects that it contains.

When views need to paint or have events handled that do not relate to the view, the observer's Paint() and HandleEvent() methods are called. The application can query the affected view for client data stored there by the application to associate the view with an application specific object. In addition, if an application object needs to know when it's position has been changed on the "screen" it can be notified of this by the observer.

• Since views may have Widgets associated with them, and as views change shape they need to tell the Widgets about these changes, there is a dependency on the Widget library.

• Much of what the view manager does involves output refresh management so it has knowledge of the graphics system.

• We would like to be able to alpha blend views together.

Support for alpha blendin