An Introduction to the Gumbo Component Architecture

by Deepa Subramaniam

The next version of Flex, code name Gumbo, will make Flex applicable to a much wider range of tasks and people. As we work to fulfill one of the three major themes for Gumbo, Design in Mind, we will provide a framework that allows developers and designers to work seamlessly together in an unfettered environment to create rich content previously unseen in Flex applications. To create this type of framework, we have taken the best of the Flex 3 component architecture (from here on out referred to as the Halo component architecture) and merged that with a new set of classes and functionality that results in the Flex 4 (Gumbo) component architecture.

This whitepaper aims to introduce the ins-and-outs of the Gumbo component architecture, serve as a foundation for building Gumbo components, and highlight where Gumbo provides functionality previously difficult in the Halo model. Wherever possible, this document links to existing Gumbo specifications that have been published on the Open Source Flex site. This whitepaper is meant to be a 'living document"; as more specifications get added and modified, sections will be amended or added. Additionally, Gumbo is in early development and everything stated in this document, including code released in public builds, is subject to change as features and design concepts are fleshed out. Some of the concepts discussed may not make it into the Gumbo release but potentially into a future release of Flex. With Gumbo builds now available on the Gumbo Downloads page, you can see Gumbo code in action but be aware that this is very early development code. Note: Gumbo classes live in the new flex.* packages whereas Halo classes continue to live in the mx.* packages.

Gumbo component architecture goals

There are several goals we aim to achieve with the Gumbo component architecture. These include:

• Design Friendly: Gumbo architecture provides a clean separation of visuals and logic including a new skinning architecture that allows for easy and powerful visual customizations.
• Composition: Gumbo components act as 'building blocks', meaning component functionality can be composited together in an easy fashion to build up (or down) to the end result the Flex designer or developer desires.
• Extensibility: Gumbo components are easy and straightforward to extend.

The following sections describe the Gumbo component architecture in detail and how each element of this new architecture satisfies one or more of the above-stated goals. While Halo satisfies some of these goals today, the Gumbo component architecture does so in a more formal and tool-able manner.

Interoperability between Halo and Gumbo

The Gumbo architecture is going to be built atop the same base classes used by the Halo architecture (e.g., UIComponent) as well as introducing new base classes which are discussed below in more detail. This means that we expect applications written in Halo to incrementally adopt the Gumbo components without difficulty. While the details remain to be worked out, we would like to see components written as part of Halo used within Gumbo containers, and Gumbo components to work inside Halo containers. Horizontal infrastructure like focus and drag and drop will be the same between the two models.

Additionally, all Gumbo applications target Flash Player 10 (codename Astro) exclusively.

A high-level view of the Gumbo architecture

Core to the Gumbo component architecture is the idea of factoring a control into different classes that handle select pieces of behavior. This clear separation allows for a better understanding of the inner workings of a component and makes the addition of new behavior easier and more predictable.

The main component class, the one whose class name matches the component's MXML tag name, encapsulates the core behavior of the component. This includes defining what events the component dispatches, the data that component represents, wiring up any sub-components that act as parts of the main component, and managing and tracking internal component state (we discuss states in more detail below).

Coupled with that component class is a skin class which manages everything related to the visual appearance of the component, including graphics, layout, representing data, changing appearance in different states, and transitioning from state to state. In the Halo model, Flex component skins were assets responsible for only one part of the graphics of a component. Changing any other aspect of a component's appearance, like layout or visualization of states, required sub-classing the component and editing the ActionScript code directly. In the Gumbo model, all of this is defined declaratively in the skin class, primarily through new graphics tags called FXG tags. To learn more about the new graphics tags in Gumbo, jump ahead to the Graphics in MXML section below.

Let's take a moment to briefly discuss states and how they play a role in skin management. The concept of States was introduced in Halo where a single state encapsulated a collection of changes to a particular view so that an application (and now in Gumbo, a component) could be partitioned into different states to govern its different views. Halo states have been expanded in Gumbo, as detailed in the Enhanced States Syntax specification, in order to make the interaction between components and states more straightforward. As a component enters and exits different states, the component manages its state internally and instructs the skin to change states in order to assume a different visual appearance. For example, when a user hovers over a Button control, the component instructs the Button skin to assume the over state. In Gumbo, when a component enters a new state, the component may instruct its skin class to assume a different visual appearance defined within the skin class. This pairing of duties allows Gumbo components to easily, and in a declarative manner, modify the visuals of a component based on interactive behavior.

The New Component Lifecycle section below, describes in detail the Gumbo component lifecycle, including how a component defines its behavior and sub-components, associates itself with a particular skin class, and manages itself in different states.

Gumbo Base Classes

As the Gumbo component architecture evolves, the need for new base classes that the Gumbo components extend has surfaced. New in the Gumbo model are 5 new base classes associated with component development: SkinnableComponent, MXMLComponent, Skin, ItemsComponent and Group. We enumerate the purpose of each class in the table below.

The Gumbo SkinnableComponent, MXMLComponent, Group, and ItemsComponent specifications provide more details about the inner workings of each new base class. The MXMLComponent specification will be posted shortly.

Graphics in MXML

New in Gumbo is a graphics tag library, called FXG (formerly referred to publicly as MXML-G), which includes graphic and text primitives, grouping structures and basic transformation capabilities. FXG includes tags for creating basic shapes like <Rect>, <Ellipse> and <Path>, tags and attributes for filling and stroking those shapes with different colors, gradients or bitmaps, as well as supports for filter, masks, alphas and blend modes on FXG elements. The FXG rendering model follows very closely the Flash Player 10 rendering model.

The Flex implementation of FXG contains high level graphical elements that all implement the IGraphicElement interface. Those graphical elements include BitmapGraphic, Ellipse, Line, Path, Rect and TextGraphic. Graphical elements do not necessarily always have a display object backing them which they draw into. For performance reasons, a graphical element will create a display object when it needs to (like when a transformation, filter or mask is applied to it) otherwise it will draw its content into a parent or sibling graphical element. APIs are provided to get the display object any graphical element is drawing into.

FXG as an Interchange Format

FXG also defines an interchange format for use in Thermo (a new designer-friendly Adobe tool for creating RIA's) and it matches the graphics capabilities described above. FXG is a defined subset of MXML meaning it does not include MXML concepts like external class references, data binding, styles, event handlers, states, transitions, and more. In certain cases, FXG tags can be used within an MXML document. By choosing what kind of file (.fxg or .mxml) the FXG lives in, or which namespace to qualify the usage with, you can decide whether you want to use MXML features together with the graphics tags. When qualifying graphics tags with the FXG namespace, the MXML features described above are off-limits for use with the graphics tags. When qualifying graphics tags with the MXML namespace, those features like data binding and states can be used. Most skin classes in the Gumbo framework are MXML documents which primarily use FXG tags to describe the visual appearance of Gumbo components.

For more information on the FXG interchange format, please refer to the FXG 1.0 specification.

Group In-Depth

Let's dive a little more into one of the new Gumbo base classes, Group. Groups contain content items. Content is an array of items that are completely owned and managed by the Group itself. Flex developers and designers work almost exclusively with a Group's content and this is why content is the default property on Group. You may notice that the Skin class, which extends from Group, places all of its declaratively defined visual elements comprising the component skin within the <content> tags. As you author Gumbo skins, you will do the same.

A Group can support UIComponents, Flash DisplayObjects, IGraphicElements (the base interface class for FXG elements), and non-visual data as content items. As discussed above, for optimization purposes, an IGraphicElement is not necessarily always a DisplayObject. During validation, the Group analyzes its content to generate an internal list of children. You as a developer or designer do not have to deal with a Group's children, only its content. The generated children are all Flash DisplayObjects, added to the Group by the Group itself via traditional Flash APIs.

Generally speaking, a Group generates its children when encountering the following content items, like so:

• A content item that is a DisplayObject, is inserted directly into the children list.
• A content item that is an IGraphicElement and provides its own DisplayObject is inserted into the children list.
• A content item that is a data object uses a generated item renderer to provide a DisplayObject which is inserted into the children list. You can use the itemRendererFunction property to conditionally decide which kind of renderer is generated for a given data object.
• All other content items should be IGraphicElements that don't provide their own DisplayObject (IGraphicElements are optimized into the smallest set of DisplayObjects possible, so it's not necessarily the case that every IGraphicElement has a corresponding DisplayObject). The Group will create one Shape for each contiguous set of these in its content, and insert that Shape into its children list. The IGraphicElements will all render into this Shape.

As for layout, Groups do not have predefined layout. A layout can be associated with a Group declaratively and modified at runtime. A Group with no layout defined will default to a simple absolute position-based layout. Every content item can fully participate in a Group's layout. Layout is discussed further in the Gumbo Layout section below.

For more information regarding Gumbo Groups, please check out the Group specification.

Gumbo Layout

Layout in the Gumbo model aims to correct some shortcomings that exist in the Halo model. One of the biggest limitations in Halo is that layout is tightly coupled with individual controls. For example, a Halo List is vertical in nature and you must use a completely different control, HorizontalList, to arrange your data items in a horizontal fashion. In order to address this, in Gumbo, layout has been decoupled from individual controls and can be defined declaratively and modified or replaced at runtime. In the Gumbo model, layouts are defined independent of the class. While containment is managed by the Group class, the layout of the Group's children is delegated to an associated layout object. This allows higher level derived classes like List, Panel, Application, TabBar, etc, to leave their layout up to the component developer rather then making arbitrary decisions as to what layout that component desires. Components will use a Group to manage containment of their content, and pass down the layout defined by the component developer to the internal Group for use in laying out its content.

Additionally, the Halo layout model has other deficiencies we aim to address in Gumbo:

• Respecting transformations: While a Halo container generally respects the scale of a component defined by the user, the rotation of the component is completely ignored. Any transformation set explicitly on a component (through the component's matrix property available on every DisplayObject) is ignored as well.
• Controlling transformations: Halo layouts allow the parent to control a component's final size and position, but does not generally give them the ability to dictate other parts of the component's transformation (specifically, rotation, scale, and possible 3D).
• Role of the origin: Halo layouts assume that the significant coordinates for a component are the bounds of the component as defined by the origin. Specifically, the Halo layout system does not take into account components with content in negative coordinates, nor does it adjust based on whether the component's content is aligned to the origin or not.

In Gumbo, we plan to correct these problems, and more. First off, Gumbo layouts can operate on various types of objects including IGraphicElements and UIComponents (from here on referred to by the general term, layout content). Rather then having layout content provide only their width and height, they can provide their measured bounds in their own coordinate system. This gives Gumbo layouts visibility into whether layout content exists in negative coordinates or is offset from the origin.

Second, in addition to users specifying explicit widths and heights, users can provide explicit values for full transformations (including scaling, rotation, and translation) on layout content. Gumbo layouts have access to this information and will use it when determining how to layout their content. Layout classes should respect explicit transformations assigned by users.

Third, the concept of content bounds will be solidified. Layouts that modify the size and position of layout content will do so based on the content's bounds (as opposed to the content's origin, width and height as in the Halo model). Similarly, since Gumbo layouts can layout all different types of objects, IGraphicElements (FXG content) will correctly include strokes in their bounds reporting to ensure proper layout fidelity.

And finally in Gumbo, while a parent container can specify size and transform on its layout content, individual components themselves will get the last word over their final layout. This allows for additional features like right-to-left layout, relative layout offsets and more.

The guts of the new Gumbo layout mechanism is covered in the Layout specification which fleshes out a new interface, ILayoutItem, that abstracts the different objects needing to be sized and arranged from the actual layout class. The new layout classes have yet to be documented in separate specifications, but currently we are planning a lightweight BasicLayout class as well as VeriticalLayout, HorizontalLayout, TileLayout and ConstraintLayout classes.

New Component Lifecycle

As described in the high-level overview section at the start of this document, the code comprising a Gumbo component falls into two basic categories: main component code and skin code. This clear separation of duties means the Gumbo model lends itself to better being able to predict where custom code should be added when you need to add new interactive behavior or visual customizations to a Gumbo component. In Halo, this distinction could often be blurry since code governing visual behavior oftentimes overlapped with interactive behavior and vice versa.

Resolving Component Skins

The first thing to understand is how a component associates itself with its correct skin class. This mechanism is currently done through CSS. A SkinnableComponent can define a skinZZ style which sub-classes set to a skin class value in order to resolve their correct skins.

Remember, a SkinnableComponent, or any subclass, means the component can have its skin swapped at runtime. In Gumbo builds, you will notice a defaults.css file that has entries like:

Button
{
skinZZ: ClassReference("flex.skin.PanelSkin")
}

or

Panel
{
skinZZ: ClassReference("flex.skin.PanelSkin")
}

These type selectors specify the correct skin class for the skinZZ style for every Gumbo skinnable component.

Skin Parts

Next to understand is the relationship between a component and its skin which expresses sub-parts of a component. The term parts is often used to refer to the constituent elements that can make up a whole component. For example, a classic scroll bar usually has 4 parts: an up button, down button, scroll track and scroll thumb. The parameterization of a part occurs through the new [SkinPart] metadata which is used to define required or optional parts of the component. These parts are defined in the component class while their visual appearance and implementation are defined in the skin class. When the skin is loaded at runtime, the skin parts are resolved and assigned to properties in the component.

Parts can be marked as required or optional by setting attributes on the [SkinPart] metadata. You'll notice that the Gumbo Scrollbar component has 2 required parts: thumb and track while upButton and downButton are optional parts. Component parts can be of any type, for example you'll notice the ScrollBar upButton and downButton parts are typed to Button.

Skin States

Now let's discuss component states and their relationship with skin classes. Components can enter and exit different states and component developers can add new states as they see fit. A component summarizes its current state by setting the currentState property, which exists on every skinnable and non-skinnable component. When a component state changes, it is often the case that the skin will change to reflect this state change. This introduces the concept of skin states, which are declared in the skin class and used to identify different states the component can assume visually. Designers can use MXML to define how the visual appearance changes as the skin's state changes. A component manages its state internally, and when a component state change occurs, the component puts the skin in the correct state in order to cause the component to update visually.

Parts and states, as well as data and component properties, are the main contracts by which a component associates itself with, and communicates with its skin.

Gumbo Component Lifecycle Methods

Now that we understand parts and states, let's discuss in more detail what the key component lifecycle methods are in a Gumbo component class. You'll notice that the Halo component lifecycle methods like commitProperties(), measure() and updateDisplayList() remain and are used in the component classes. These methods serve the same purpose they did in Halo: commitProperties() is used to carry out the setting of newly set properties, measure() is used to determine component size and updateDisplayList() is used to position sub-components and draw them to the screen. For the most part, skinnable Gumbo components typically delegate their measurement and rendering to the skin but they can add view specific code to these methods as appropriate. In addition to these methods, new methods have been added to the Gumbo component lifecycle to manage skins and parts. Where appropriate, these new methods have the same invalidation mechanism that existed in Halo, in order to batch updates in a well performing manner.

Loading Skins

Let's look at component lifecycle methods added to support the new Gumbo model. Lets start with the most important pair of skin managing methods: SkinnableComponent.loadSkin() and SkinnableComponent.unloadSkin(). These methods manage the loading and unloading of skins and re-assignment of skin elements when a style change affects a component skin. Both methods get called in the commitProperties() phase of the component lifecycle and are typically not invoked directly in user code. unloadSkin() gets called to remove references to skin parts, and remove event listeners acting on the component. loadSkin() loads the skin class for a component based on the skinZZ style, finds the skin parts in the skin class and assigns them to properties in the component, and adds event listeners to the component. loadSkin() and unloadSkin() are not typically overridden when writing Gumbo components.

Managing Skin Parts

Related to the setting and unsetting of skin parts are two important methods: SkinnableComponent.partAdded() and SkinnableComponent.partRemoved(). Whenever a skin part is added/assigned or removed/un-assigned, partAdded() and partRemoved() get invoked to handle the setup and teardown of skin parts. partAdded()'s responsibility include attaching event listeners to newly instantiated parts as well as pushing data or properties down to the skin part. Similarly, partRemoved() takes care of removing event listeners acting on the removed part as well as any other cleanup that is required when a part is removed.

Managing Skin States

Next is a pair of important methods that manage skin states. When component state changes, it is the component's responsibility to set the appropriate skin state. This happens through the SkinnableComponent.commitSkinState() and SkinnableComponent.invalidateSkinState() methods. How in the Halo model, you would never call commitProperties() directly but instead call invalidateProperties() to force the component to go through a validation phase, you never call commitSkinState() directly. Instead, when the component state changes, the component calls invalidateSkinState() which eventually invokes commitSkinState() in order to set the new state of the skin. In addition to these two methods is another important skin-related method: SkinnableComponent.getUpdatedSkinState(). getUpdatedSkinState() method which returns the name of the state the skin should enter based on current interaction. This method is the main extension point when adding new states to a skin in addition to declaring the skin state in the skin class. The reason the skin state management is factored out into a set of methods is for ease of use for the developer. It's common for developers to want to extend existing components and add new behavior. As part of that, they may want to add additional states. If the code to set the currentState was scattered across the component, it would be difficult to extend the logic that defines what state the component is in at any given moment. By centralizing all the code that sets the current state into a single location, a developer can easily override and extend this logic in a single place to meet their needs.

Existing Gumbo Components

Now that Gumbo builds are available, you will notice that several Halo components have been written in the Gumbo model. Some of these components are in very early development and so they may not necessarily follow the tenets laid down in the New Component Lifecycle section above. Let's discuss these components in detail a bit more to identify key Gumbo concepts.

Button

The Gumbo Button was the first component to be written in the new model. A Gumbo Button can have its skin modified at runtime and as such, extends from SkinnableComponent. A Gumbo Button does not have any sub-parts, so there is no [SkinPart] metadata decorating the class.

You'll notice that the Button component class manages its state internally via methods like isHoveredOver(), isKeyboardPressed(), isDown(), isMouseCaptured(), etc in order to ascertain its current state. In each of those methods, invalidateSkinState() is called to update the skin state accordingly.

The Button skin class, ButtonSkin.mxml, uses MXML graphic elements to describe its visual appearance within the <content> tag. You'll notice that a Gumbo TextBox graphic element is used to render a Gumbo Button's label. And finally, at the very top of the skin file, the states the ButtonSkin class can enter are defined: up, over, down and disabled. Remember, it is the responsibility of the Button class to put the Button skin into its correct skin states.

CheckBox/RadioButton

As the CheckBox and RadioButton controls were written in the Gumbo model, it became clear that we needed to handle toggleability and selectability of a button-based control through a separate class. The Gumbo Button class did not need toggleability since that was not a feature of all Button controls (remember, in the Gumbo model, each core component class only contains functionality that is absolutely essential to that component). In the Halo model, toggleability was added to Button and all sub-classes inherited it, like CheckBox and RadioButton. Instead of doing this, in the Gumbo model we created a new class, ToggleButton, that extends from Button and added in toggle and selection behavior. The Gumbo CheckBox and RadioButton controls extend from this ToggleButton class in order to inherit that behavior. Thus, you'll notice that the CheckBox and RadioButton classes are very lightweight and use inherited behavior from ToggleButton and Button.

The CheckBox and RadioButton skin classes (CheckBoxSkin.mxml and RadioButtonSkin.mxml) are similar to the ButtonSkin class. At the top of each skin class, the states the skin can assume are defined. FXG tags are used to declaratively define the visual appearance of the component within the skin's <content> tag and a Gumbo TextBox component is used to display the control's label.

Panel

The Gumbo Panel component is the first to extend from ItemsComponent, a new model class that was added to represent all skinnable controls that can contain child elements. ItemsComponent defines events that are dispatched when items are added and removed from the component. Additionally, ItemsComponent offers methods to add, remove, grab and swap content items as well as provide renderers for those items. ItemsComponent is one of the first classes to implement the partAdded()/partRemoved() methods to handle pushing content and layout down to its skin part. ItemsComponent has only one skin part, contentGroup which is of type Group, and it is a required skin part. The contentGroup part is the root Group object that contains all of an ItemsComponent's content items. Additionally, an ItemsComponent can have its layout set dynamically and that layout gets pushed down to the contentGroup when laying out its children. To learn more about the inner workings of the ItemsComponent class, please refer to its specification.

Since ItemsComponent takes care of much of the heavy lifting needed for displaying and managing content items, the Panel class itself is pretty small. The Panel skin class (PanelSkin.mxml) is straightforward as well. No skin states are defined and so the class solely consists of the markup tags needed to visually represent a Panel. The important thing to note is that there is a Group tag, whose id is contentGroup, and this is a skin part definition. It is into this Group that the Panels' content items get placed and arranged by whatever layout is dictated by the layout property.

Application

The Gumbo Application extends from ItemsComponent and is relatively small since ItemsComponent manages much of the functionality. The Application skin class (ApplicationSkin.mxml) contains a rectangle whose background color is linked up to the Application's backgroundColor style and the contentGroup Group object, as required by ItemsComponent. Like all ItemsComponents, the layout property can be set dynamically to a layout class (the default is flex.layout.BasicLayout). There are a few Application-specific properties defined in the class, like viewSourceURL and backgroundColor. Additionally, Flash Player properties like frameRate and scriptTimeLimit are also defined. The Application class is still a work in progress and details regarding skin styles and SystemManager interactions are pending. You can get more information on the Gumbo Application by checking out its specification.

TextInput/TextArea

The Gumbo TextInput component allows users to enter and edit a single line of single-styled text. It is based primarily on the new text capabilities available in Flash Player 10. Similarly, the Gumbo TextArea component supports entering and editing multiple lines of multi-styled text. Both controls have a required skin part, textView, which is a new component that handles selectability, editability and scrollability of Gumbo text controls. The text-aware Gumbo controls are in very early development and functionality like scrolling has yet to be implemented yet. For more information on both components, please refer to the TextInput and TextArea mini-specifications.

Range/TrackBase

The Gumbo Range class was written as a base class for skinnable components that can express a value within a legal range denoted by a minimum and maximum value. The Range class defines properties like value, minimum, maximum. Range also defines the valueInterval and stepSize properties. valueInterval constrains value to multiples of itself, while stepSize is used to step the value by a certain amount. Gumbo components like NumericStepper, ScrollBar and Slider will extend from Range since they require this functionality. Please see the Range specification for details.

The Gumbo TrackBase class is a base class that extends from Range and is the parent class of the Gumbo ScrollBar and Slider. It provides much of the shared functionality between ScrollBar and Slider such as handling thumb dragging. TrackBase has two required SkinParts called thumb and track. TrackBase also introduces the idea of separating the positioning of the thumb and the actual value of the thumb. For further information about TrackBase, please refer to the TrackBase specification.

ScrollBar

The Gumbo ScrollBar component extends from the TrackBase class. It inherits the thumb and track SkinParts, but also has two optional SkinParts called incrementButton and decrementButton. You'll notice in the ScrollBar skin classes (VScrollBarSkin.mxml for a vertical scrollbar and HScrollBarSkin.mxml for a horizontal scrollbar), the <content> tags define the components that represent those skin parts. The id set on those components match the id of the properties in the ScrollBar component class in order to hold references to the skin parts. Additionally, those skin parts define separate skin classes for defining the visual appearance of each individual part. You'll notice the skinZZ style is set inline on the decrementButton tag to specify the ScrollBarUpButtonSkin class as the skin class to use in rendering the decrementButton. Please refer to the ScrollBar specification for more information.

Spinner/NumericStepper

The Gumbo Spinner class is the parent class of the Gumbo NumericStepper control. A Spinner extends Range, and thus has all of the range management functionality like stepping and constraining the value to a maximum and a minimum. A Spinner exposes two required skin parts, incrementButton and decrementButton which control the incrementing and decrementing of the Spinner's value. For a better overview of Spinner, please refer to the Spinner specification.

The Gumbo NumericStepper control extends Spinner and exposes one required SkinPart, a TextInput control called textInput, in addition to the inherited incrementButton and decrementButton. The Gumbo NumericStepper allows its TextInput control to display and edit the value. For more information, please refer to the NumericStepper specification.

Slider

The Gumbo Slider class is the base class for Slider controls. It extends TrackBase in order to get all of the track management functionality, while adding functionality like liveDragging, track clicking and keyboard navigation. Current builds include the derivative classes, HSlider and VSlider, for horizontal and vertical sliders. Currently we support one-thumb Slider controls. More information can be found at the Slider specification.

List

The Gumbo List component aims to be much lighter and flexible then its Halo counterpart. List extends the new Selector class, which is a sub-class of ItemsComponent. Selector's purpose is to be the base-class for any skinnable component that supports single selection. Multiple selection support will be built directly into the List class. ItemsComponent handles the item renderer functionality needed by the Gumbo List control. The itemRenderer property can be used to declare a new class used to generate a renderer for a display item. The itemRendererFunction property can be set to a method that can conditionally, at runtime, determine what renderer to generate for a given display item. To learn more about ItemsComponent and Selector, please refer to their joint specification.

Additionally, we are currently investigating and prototyping virtualization support for the Gumbo List. Specifications describing that behavior are pending.

Advanced Animations in Gumbo

The effects infrastructure in Gumbo will be modified to address certain limitations that exist in the Halo model. A Halo IUIComponent contains a lot of effects-specific knowledge, specifically helper methods that are called directly by effects classes. This meant that in Halo, an effect expected an IUIComponent component for animation. In Gumbo, we want applications to be able to apply effects to any kind of component as well as non-component objects like the new graphical elements. We are looking to write new effects and infrastructure that can operate generically on any target object.

Additionally, we are investigating advanced functionalities like the ability to blend effects that animate the same target element or overlap in some fashion. Imagine an enter/exit effect that animates the same view. In the Halo model, the enter effect would be interrupted in order to play the exit effect. In the Gumbo model, we're looking to provide more intelligent effects where effects can detect that there is some overlap and blend together to provide a smooth transition. Other areas of investigation include animation of arbitrary types (for example, colors) and enhanced functionality in the underlying Tween timing engine.

The Gumbo advanced effects work is currently being prototyped and specifications will be posted as they become available.

Advanced Text Functionality

The Gumbo components will leverage the new text features available in Flash Player 10 (codename Astro). This provides Flex with an entirely new text engine that will give us significantly more control over text elements. This includes richer control over text appearances, an object oriented text model, a richer markup language as well as support for right-to-left text. With the new text features available, text elements like <div>, <p>, <span> and <a> are represented as ActionScript objects which developers can query and modify. See the specifications on text for more information as they become available. It is important to note that current Gumbo component skins use text components that encapsulate the new Flash Player 10 text features.