Gumbo Viewport - Functional and Design Specification
Summary and Background
A viewport displays the subset of its content that falls within a clipping rectangle whose width/height match the viewport's. By resetting the clipping rectangle's origin, one can survey all of the viewport's content, even though the content's width and height are much larger than the viewport's. This is called "scrolling".
This feature adds viewport functionality to the Group and DataGroup classes. It also extends the layout classes to enable specifying viewport geometry.
Detailed Description
The Flash Player supports scrolling with the Rectangle valued DisplayObject scrollRect property. The DisplayObject's display list is clipped to the scrollRect and displayed at the DisplayObject's origin. Using scrollRect, one can realize the usual scrolling idiom by making the scrollRect's width and height the same as the DisplayObject's, and by binding the scrollRect's x,y coordinates to the values of a horizontal and vertical scrollbar. The scrollbars' maximum values must be configured to match the bounds of the Display Object's children, and the scrollbars' thumb sizes should reflect the relative size of the Display Object and the size of the bounds of its children.
To allow a Group or a DataGroup to function as a viewport, we've added a pair of properties to GroupBase (their common superclass) that define the overall width and height of the viewport's content, contentWidth and contentHeight. We've also added a pair of properties that define the origin of the viewport's clipping rectangle, verticalScrollPosition and horizontalScrollPosition, and a boolean clipContent property that enables scrolling. If clipContent is true, then the Group's scrollRect will be set.
Here's an example of the viewport properties:
<Group clipContent="true" width="142" height="75"
horizontalScrollPosition="46" verticalScrollPosition="100">
<Image source="curly.jpg" width="600" height="376">
</Group>

Scrolling is enabled when the viewport's content width or height is larger than its width or height and clipContent is true. Group and DataGroup will not include support for automatically displaying scrollbars when scrolling is enabled (as Halo did). A separate skinnable component called FxScroller will provide the conventional arrangement of scrollbars and a viewport.
The "Group as Viewport" feature corresponds to a set of changes applied to GroupBase, LayoutBase, and the LayoutBase subclasses BasicLayout, VerticalLayout, and HorizontalLayout. The viewport API is defined by a new interface called IViewport. Explicit support for viewports has been added to the ScrollBar classes.
GroupBase gets five new properties, all of which are defined by the new IViewport inteface:
All of the new properties are bindable except the clipContent flag. All but the first two are delegated to the group's layout. LayoutBase provides the implementation of the verticalScrollPosition, horizontalScrollPosition, and clipContent properties.
The layout classes have been updated to initialize their (GroupBase) layoutTarget's contentWidth,Height at updateDisplayList() time. Additional properties have been added to VerticalLayout and HorizontalLayout to enable one to specify the relative size of the viewport in terms of the number of visible rows or columns. The names and semantics of the new layout properties are largely compatible with Halo:
VerticalLayout
HorizontalLayout
The viewport feature does not change the default behavior of the Gumbo Group or the layout classes. In other words, tests and applications written before the feature was introduced should continue to work, unchanged.
The definition and implementation of the Group layout property have been revised to allow one to specify layout object values. Previously, one could only specify the layout property's class:
<Group layout="flex.layout.VerticalLayout">
your column of items here ...
</Group>
The type of the Group layout property was Class and the MXML compiler handled this special case by mapping the property value string to Class object. The actual ILayout instance was private to Group and was initialized by calling the layout class constructor with no arguments.
This approach complicates configuring layout classes, since one would have to create subclasses whose null-constructors configured the layout appropriately. To remedy this, the type of the Group layout property has been changed to LayoutBase and layouts must be specified with a subelement. Like this:
<Group>
<layout>
<VerticalLayout gap="4" rowCount="7" rowHeight="20" />
</layout>
your column of items here ...
</Group>
To simplify creating rows and columns of items, and to provide something analagous to the Halo HBox and VBox classes, wrapper classes called HGroup and VGroup have been defined. These two classes are simply Groups with a predefined layout and layout geometry properties that delegate to the predefined layout. This enables one to write:
<VGroup gap="4" rowCount="7" rowHeight="20">
your column of items here ...
</VGroup>
API Description
mx.core.IViewport Interface
The viewport API. Implemented by GroupBase and TextView, supported by the FxScroller component.
mx.core.ScrollUnit Interface
Enumerated type for the IViewport getVerticalScrollPositionDelta() and getHorizontalScrollPositionDelta() methods. All of these constants have the same values as their flash.ui.Keyboard counterparts, except PAGE_LEFT and PAGE_RIGHT, for which no keyboard key equivalents exist.
mx.layout.LayoutBase Class
The base class for layouts and the type of the GroupBase layout property. The methods and properties that just implement the IViewport interface are not shown here.
Additions to the mx.layout.VerticalLayout class
This section just lists the methods and properties added to the VerticalLayout class for the sake of the viewport feature.
Additions to the mx.layout.HorizontalLayout class
This section just lists the methods and properties added to the HorizontalLayout class for the sake of the viewport feature.
mx.components.VGroup class
A Group with a VerticalLayout. All of the VerticalLayout properties
exposed by this class (and listed below) are simply delegated to the
layout property. The layout property should not be set or configured
directly.
mx.components.HGroup class
A Group with a HorizontalLayout.
All of the HorizontalLayout properties exposed by this class are simply
delegated to the layout property.
The layout property should not be set or configured directly.
B Features
When fixed row heights (variableRowHeight = false) are requested for a VerticalLayout, or fixed column widths for a HorizontalLayout, it's usually preferable not to specify the fixed size. It's more reliable to allow the fixed size to be computed, to accomodate differences in fonts and
rendering on different platforms and potentially for different configuations of the application. The existing API supports this by using the size of the first item, if fixed size items are requested and an explicit size isn't provided. A more flexible approach would be to allow the developer to specify a "typical" item instead. Such an item might not appear in the layout at all, it would be designed to consume as much space as typical items require.
Methods that compute the scroll "delta" to expose a particular item index, or to top/bottom/center justify it would be useful. Scrolling applications often want to bring a particular item into view - if it isn't already - and doing so now requires significant work.
Something comparable to the Halo TileLayout needs to be provided.
A viewport's "step" and page size can be direction and content dependent. For example, the step size for a VerticalLayout is as big as the row just above the top of the scrollRect for a step up, and as big as the row just below the bottom of the scrollRect for a step down. Obviously, if the viewport contains variable height rows, the step size depends on the step direction and the the size of the row that comes next in that direction. The current ScrollPositionDelta methods also take partial visibility into account, which means that even with fixed sze items, the step size varies depending on the partial/total visibility of the next item. There's a significant mismatch between ScrollBar's simple stepSize property and a viewport's support for stepping up/down or left/right. ScrollBar's pageSize has similar problems, plus it's used to define the viewport's size for the sake of the thumb geometry. More about this here http://bugs.adobe.com/jira/browse/SDK-17288. ScrollBars and their myriad superclasses will need refinement.
Additional Implementation Details
Nothing applicable yet.
Prototype Work
This feature has been implemented.
Compiler Work
No.
Web Tier Compiler Impact
None.
Flex Feature Dependencies
This feature is part of the basic Gumbo infrastructure. Many other features and components depend on it.
Backwards Compatibility
This feature is not intended to be compatible with existing applications or components.
Syntax changes
Behavior
Warnings/Deprecation
Accessibility
None.
Performance
ScrollRect based scrolling performance is remarkably good.
Recently we've learned that even seemingly inconsequential operations on a DisplayObject's scrollRect, like getting its value or setting it to null, cause the FlashPlayer to allocate large data structures. The viewport API has been revised to ensure that by default, scrolling isn't enabled, i.e. the scrollRect is not used. To ensure that the scrollRect property isn't needlessly queried or set to null will require additional implementation work.
Efficient support for large layouts will require "virtualization".
Globalization
There aren't any globalization issues.
Localization
No issues at this time.
Compiler Features
Framework Features
Issues and Recommendations
See the B features section.
Documentation
QA
Yes
|
 |
Rather then creating a sub item for Group class, why not to define the way of layout follow like that
Too complicated to define:
<Group>
<layout>
<VerticalLayout gap="4" rowCount="7" rowHeight="20" />
</layout>
your column of items here ...
</Group>
Simple way:
<Group layout="vertical">
your column of items here ...
</Group>
The way of define a subitem will reproduce to much error. Keeping the way developers are used to like in Titlewindow, Panel, is more polilical practicies.
Regards
igorcosta.org