Alex Harui is the guru of turning a Flex 4 Spark List into a look-alike for the old Flex 3 component using skins and a custom ItemRenderer. Alex has used List + ItemRenderer to make a DataGrid, DateField, ColorPicker, Menu + MenuBar, and even an XML-based TreeList. Unfortunately, Alex’s TreeList assumes incoming XML, and I needed a TreeList that could display a simple object hierarchy (root node with children, and those children have children, etc.). Since I couldn’t find exactly what I wanted, I decided to build it myself.

Flattener

The key step to getting a hierarchy of objects to display as a list is: flatten the list, duh! Or at least flatten the part of the tree you wish to display. So, I built a simple adapter class that turns an object hierarchy into an ArrayList that can be given directly to a List‘s dataProvider.

Here’s the actual flattener, but with just the comments not the code:

public class MyObjFlattenedList extends ArrayList {
 
    //the root object
    private var _root:MyObj;
 
    //list of open nodes
    private var _openList:Array;
 
    public function MyObjFlattenedList(root:MyObj) {
        _root = root;
        _openList = [];
        reset();
        ...
    }
 
    public function reset(openList:Array = null):void {
        //init the flattened list, starting at root
        _openList = (openList == null ? [] : openList);
        var a:Array = [];
        addItemToList(_root, a);
        this.source = a;
    }
 
    private function addItemToList(obj:MyObj, a:Array):void {
        //recursively walk obj and all of its "open" children to build
        //a flattened list that is returned in array a
    }
 
    public function isItemOpen(obj:MyObj):Boolean {
        //true if obj has children and is "open"
    }
 
    public function openItem(obj:MyObj):void {
        //add all of obj's children (if any) to the list
    }
 
    public function closeItem(obj:MyObj):void {
        //remove all of obj's children (if any) from the list
    }
    ...
}

There’s really not much to it. When instantiated with a root object, the object hierarchy is walked recursively to build a flattened list of all the open nodes. Once the initial list is built, openItem() can be called to open a node, and add all its children to the list. Alternately, closeItem() can be called to close a node, and remove all its children from the list.

Design

I used some basic styling and skinning, but the ItemRenderer does the majority of the work. Here’s the abbreviated version of MyObjRenderer.mxml with all the boring stuff edited out:

<?xml version="1.0" encoding="utf-8"?>
<s:ItemRenderer
    xmlns:fx="http://ns.adobe.com/mxml/2009" 
    xmlns:s="library://ns.adobe.com/flex/spark"
    width="100%"
    autoDrawBackground="false">
 
    <fx:Script>
        <![CDATA[
            [Bindable] private var _obj:MyObj;
            [Bindable] private var _hasChildren:Boolean = false;
 
            private var _list:MyObjFlattenedList;
 
            override public function set data(val:Object):void {
                super.data = val;
 
                if (val != null) {
                    _obj = val as MyObj;
 
                    var ownerList:List = owner as List;
                    _list = ownerList.dataProvider as MyObjFlattenedList;
 
                    btn.selected = _list.isItemOpen(_obj);
                    _hasChildren = (_obj.children != null && _obj.children.length > 0);
                }
            }
 
            private function toggleHandler():void {
                if (btn.selected) {
                    _list.openItem(_obj);
                } else {
                    _list.closeItem(_obj);
                }
            }
        ]]>
    </fx:Script>
 
    <s:states>
        <s:State name="normal" />
        <s:State name="hovered" />
        <s:State name="selected" />
    </s:states>
 
    <s:Rect ...>
 
    <s:HGroup ...>
        <s:ToggleButton id="btn" click="toggleHandler()" visible="{_hasChildren}" ... />
 
        <s:Group id="dot" visible="{!_hasChildren}" ... />
 
        <s:Label ... />
    </s:HGroup>
</s:ItemRenderer>

Each rendered item has a background Rect and a Label. But most importantly, each row has either a ToggleButton (if the object has children) or some non-interactive visuals (if the object doesn’t have children it just gets a dot). The toggle button is the key interactive element used to open or close the node, everything else is part of the visual gravy added to make the list look good.

Focusing on the functional stuff, if you look in the script block, you’ll see two functions: a data() setter and a toggleHandler() to handle toggle button clicks. As expected, clicking the toggle button calls openItem() or closeItem() on the flattener adapter which adds or removes children from the flattened list, respectively. The setter mostly sets up the local variables, but it notably computes if the object has children or not, and also sets the initial state of the toggle button.

Conclusion

With just a little effort, we can have a nice usable Spark TreeList component that looks decent. More importantly, we have total control and can make the TreeList look like anything our designer can throw at us. As is always the case, the combo of List + ItemRenderer proves to be awesome. I tried to cover all the interesting pieces, but for the details, you’ll need to check out the source code.

Here’s the finished product (view source enabled):

Use it and enjoy.

Files

• ObjTreeList (fxp download)

The fancy clock skin overlays a very simple clock component. The Clock component is quite underwhelming, but here it is in all of its abbreviated glory:

public class Clock extends SkinnableComponent {
    public var secAngle:Number = 0.0;
    public var minAngle:Number = 0.0;
    public var hourAngle:Number = 0.0;
    private var _timer:Timer;
    private var _tween:GTween;
 
    public function Clock() {
        ...
        _tween = new GTween(this, 2, ...);
        _timer = new Timer(2000,30);
        _timer.addEventListener(TimerEvent.TIMER, tickHandler);
    }
 
    private function tickHandler(e:TimerEvent):void {
        var t:Date = new Date();
 
        var h:Number = t.getHours();
        var m:Number = t.getMinutes() + h * 60;
        var s:Number = t.getSeconds() + m * 60;
        var ms:Number = t.getMilliseconds();
 
        _tween.proxy.secAngle = -90 + s * 6 + ms * 0.006;
        _tween.proxy.minAngle = -90 + s * 0.1;
        _tween.proxy.hourAngle = -90 + (s / 120);
    }
    ...
}

At the core of the Clock component is a single timer. When the timer fires, it uses the current date to compute the angle of the hour hand, minute hand, and second hand. The actual motion of the hands is managed via the awesome proxy functionality in Grant Skinner’s GTween library.

All the interesting FXG action takes place in the skin, so let’s check it out:

<?xml version="1.0" encoding="utf-8"?>
<s:Skin
        xmlns:fx="http://ns.adobe.com/mxml/2009"
        xmlns:s="library://ns.adobe.com/flex/spark"
        creationComplete="complete()">
 
    <fx:Metadata>
        [HostComponent("components.Clock")]
    </fx:Metadata>
 
    <fx:Script>
        <![CDATA[
            private function complete():void {
                ...lots of programmatic FXG here...
            }
        ]]>
    </fx:Script>
 
    ...lots of vanilla FXG here...
 
    <s:Path rotation="{hostComponent.minAngle}" ...
    <s:Path rotation="{hostComponent.hourAngle}" ...
    <s:Path rotation="{hostComponent.secAngle}" ...
</s:Skin>

Getting data to the skin is done via the standard binding to hostComponent. There is no need for the more complicated partAdded() and partRemoved() mechanism, because the Clock component is not intended for general use, unlike my previous components: Terrific TabBar, SuperTextInput, and Drawer.

The skin has a big block of programmatic FXG skinning, done in actionscript code inside the complete() handler which is fired by the creationComplete event. It also has a big block of vanilla MXML declarative FXG skinning, which, most importantly, includes the clock hands and the previously mentioned binding to hostComponent.

By its nature, a clock has a lot of identical elements that are positioned in a circle. The obvious attack is to put the repeated elements in a loop, or set of loops, and go the programmatic route to construct the skin. For example, the long thin ticks along the outer ring are constructed with a double loop. Here’s the relevant snippet of code from inside the complete() handler:

for each (var i:int in [0,30,60,90,120,150,180,210,240,270,300,330]) {
    for each (var j:int in [6,12,18,24]) {
        var p:Path = new Path();
        p.data = "M 174,-0.5 L 184,-0.5 184,0.5 174,0.5 Z";
        p.x = 250;
        p.y = 250;
        p.rotation = i + j;
        p.fill = gray;
        this.addElementAt(p, 1);
    }
}

A new Path element is created and its data property is set. Our tick mark is 10px long, but only 1px wide. With each iteration, a tick mark is created and rotated into place. There are two important tricks in this code that are worth pointing out. First, the rotation origin is at (0,0) for each element, so we must construct our path from -0.5 to 0.5 for it to rotate correctly. Second, we must use addElementAt() to place each element into the proper layer of the drawing because the programmatic FXG code runs after all the vanilla (aka non-programmatic) FXG has been drawn.

Conclusion

No one in their right mind would ever build a clock skin like this. To do this the right way, you’d definitely want to use an image or two to construct the skin. The only reason I went the programmatic FXG skinning route was to verify to myself that it could be done. So, yes it can be done, and I enjoyed the trip.

Files

• AnalogClock (download)

The Flex 3 Way

To give a concrete example, I’ll build a blog layout (yes, another blog layout) with a header, footer, sidebar, and main content areas. But before we get started, let’s review the old Flex 3 way:

<mx:HBox id="header">
    <mx:Image source="@Embed('assets/logo.png')" />
</mx:HBox>
 
<mx:Canvas id="body" width="800">
    <mx:Text text="main content" width="600" />
 
    <mx:VBox id="sidebar" x="600" width="200">
        <mx:Text text="Sidebar" />
        <mx:Text text="sidebar content" width="100%" />
    </mx:VBox>
</mx:Canvas>
 
<mx:VBox id="footer">
    <mx:Text text="2010 saturnboy" styleName="footer" />
</mx:VBox>

The above code comes from a previous post, Designing in Flex 3, but has been modified to make sense here. You’ve got you basic blog design: a box for the header, footer, and body, where body is subsequently is divided into a main content area and a sidebar.

The 3-in-4 Way, aka The Wrong Way

The unfortunate next step in a Flex developer’s evolution is what I like to call the Flex 3-in-4 way. This is a the way of neanderthals, which is to say, it is an evolutionary dead end. If you ever have the bad luck to see 3-in-4 code, you can be sure you are dealing with a novice Flex 4 developer. In general, the 3-in-4 way consists of making the simple transcription: Canvas → Group, HBox → HGroup, VBox → VGroup. But the most damning tipoff of a 3-in-4 developer is the assertion that one is now a Flex 4 developer and the learning curve wasn’t all that bad. While I do think Flex 4 is more of an evolutionary release than a revolutionary release, it’s different enough. And it is particularly different on the design side of the framework, how it handles skins, layout, etc.

If we just transcribe the above example, we get some classic 3-in-4 code:

<s:HGroup id="header">
    <s:Label text="Multi Content Area Example" styleName="header" />
</s:HGroup>
 
<s:Group id="body" width="800">
    <s:Label text="main content" width="600" />
 
    <s:VGroup x="600" width="200" styleName="sidebarBox">
        <s:Label text="Sidebar" styleName="title" />
        <s:Label text="sidebar content" styleName="sidebar" />
    </s:VGroup>
</s:Group>
 
<s:VGroup id="footer">
    <s:Label text="2010 saturnboy" styleName="footer" />
</s:VGroup>

*Barf*, please not do this. This code has all the same issues as the Flex 3 code in the first example, and moreover it is a slap in the face of The Flex 4 Way and all of its improvements.

The Flex 4 Way

Yes, there is a Flex 4 Way and it looks like this.

First, we rewrite the main app using a custom container. Ignoring the specifics of the custom container for a moment, here is the re-written main app (minus some clutter):

<containers:headerContent>
    <s:Label text="Multi Content Area Example" styleName="header" />
</containers:headerContent>
 
<containers:sidebarContent>
    <s:RichText left="0" right="0" styleName="sidebar">
        <s:content>
            <s:p fontSize="20">Sidebar</s:p>
            <s:p>sidebar content</s:p>
        </s:content>
    </s:RichText>
</containers:sidebarContent>
 
<containers:footerContent>
    <s:Label text="2010 saturnboy" styleName="footer" />
</containers:footerContent>
 
<s:RichText left="0" right="0">
    <s:content>
        <s:p fontSize="30">Content</s:p>
        <s:p>main content</s:p>
    </s:content>
</s:RichText>

As you can see, the main app is now a nice set of semantic buckets, one for each of the content areas. Header stuff goes in the headerContent bucket, footer stuff goes in the footerContent bucket, etc.

Building a Multi Content Area Container

Second, we need to create a custom container with the nice set of semantic buckets used in the above code. This is achieved by following a straightforward formula:

1. Extend SkinnableContainer – Extend SkinnableContainer or some child class. In our sample app, our custom container extends Application (which extends SkinnableContainer).
2. Add Buckets – add some content buckets (in the form of xxxContent) as Arrays. These become the MXML tags used to bucket components together. Each content bucket has a public getter, but most importantly a public setter that accepts an incoming Array of IVisualElements and uses the magical mxmlContent property to assign it to the associated SkinPart.
3. Add SkinParts – add some matching SkinParts (in the form of xxxGroup) as spark Groups. There are used in the custom skin to display the content. Also, I usually set required="false" to make everything optional.
4. Add partAdded() & partRemoved() – override the new Flex 4 skinning lifecycle methods to wire the incoming content to the outgoing SkinPart.

The custom component code is actually easier to follow then the description. Here is a custom container with only one additional content bucket, sidebarContent, and its matching SkinPart, sidebarGroup:

package containers {
    import spark.components.Group;
    import spark.components.Application;
 
    public class MainApp extends Application {
        [SkinPart(required="false")]
        public var sidebarGroup:Group;
 
        private var _sidebarContent:Array = [];
 
        public function MainApp() {
            super();
        }
 
        [ArrayElementType("mx.core.IVisualElement")]
        public function get sidebarContent():Array {
            return _sidebarContent;
        }
        public function set sidebarContent(value:Array):void {
            _sidebarContent = value;
            if (sidebarGroup) {
                sidebarGroup.mxmlContent = value;
            }
        }
 
        override protected function partAdded(partName:String, instance:Object):void {
            super.partAdded(partName, instance);
 
            if (instance == sidebarGroup) {
                sidebarGroup.mxmlContent = _sidebarContent;
            }
        }
 
        override protected function partRemoved(partName:String, instance:Object):void {
            super.partRemoved(partName, instance);
 
            if (instance == sidebarGroup) {
                sidebarGroup.mxmlContent = null;
            }
        }
    }
}

Following the four steps: we extend Application, have a sidebarContent bucket and its associated sidebarGroup SkinPart, and override partAdded() and partRemoved() to wire everything together.

Skinning a Multi Content Area Container

Skinning in Flex 4 is awesome, and like everyone says, it’s easily one of the best new features in the framework. While I find the skinning process fairly straightforward, I would never call it trivial, mostly due to the depth and flexibility of the skinning system.

We need a custom skin for our custom multi content area component. This is probably the 10% case for skinning, but it’s also the coolest. In my experience, an average Flex 4 app has many Button skins (like 10 or even 20), a few default component skins (skins for List, DropDownList, TextInput, etc.), and maybe only two or three skins for custom components.

The skin itself is nothing special. To display our custom component’s SkinParts, we simply include a Group with the matching id attribute. For example, our skin will include a <s:Group id="sidebarGroup" /> to display the sidebarGroup SkinPart. Just rinse, wash, repeat, to add all of our custom content areas in the container to the skin.

Here is a trivial skin:

<s:Skin ... >
    <fx:Metadata>
        [HostComponent("containers.MainApp")]
    </fx:Metadata> 
 
    <s:states>
        <s:State name="normal" />
        <s:State name="disabled" />
    </s:states>
 
    <s:VGroup left="40" right="40" top="40" bottom="40" gap="20">
        <s:Group id="headerGroup" width="100%" />
        <s:Group id="contentGroup" width="100%" />
        <s:Group id="sidebarGroup" width="100%" />
        <s:Group id="footerGroup" width="100%" />
    </s:VGroup>
</s:Skin>

In this trivial skin, we just shove all the content groups (including SkinnableContainer‘s default Group, contentGroup) into a VGroup. Also note, we correctly set HostComponent to our custom container. If you are thinking, "Hey, this skin looks similar to the Flex 3 and 3-in-4 example code, just minus the content" that’s exactly the point.

Lastly, we wire out skin to our custom component via CSS:

containers|MainApp {
    skinClass:ClassReference('skins.TrivialAppSkin');
}

Using skinClass to wire a skin to a component is so 2009. The sample app has its CSS inline, but in any real app I’ll always put this in an external file.

Conclusion

After this, there’s really not much more to say. You can certainly create a more complicated arrangement of the multiple content areas by making a more complicated skin. I’ve done exactly this in the final sample, which includes three different skins and a skin switcher (click 1, 2, or 3 to switch skins).

» view MultiConentArea sample (view source enabled)

Files

• MultiContentArea (download)

Here are some quick examples:

1

2

3

If we zoom in on example #1, which starts with black (#000000) and has deltas of 4, 1, 0.25, we see the following:

The diagram shows the first ten rows of the gradient. The delta values are accumulated with each row, and only the whole part of the resulting color value is used (aka I take the floor of each color bit). So in this example, using the fractional delta of 0.25 results in exactly one additional blue bit every four rows. Ahhh, perfect!

The Code

No need to use some fancy new language, I wrote a simple PHP program to handle commandline input and output a perfect PNG gradient. The interesting part is the function that generates and saves the gradient:

function build_image($filename, $w, $h, $color, $delta) {
  $img = imagecreatetruecolor($w, $h);
 
  $c = imagecolorallocate($img, $color[0], $color[1], $color[2]);
  $d = $delta;
 
  for ($y = 0; $y < $h; $y++) {
    imagefilledrectangle($img, 0, $y, $w - 1, $y + 1, $c);
 
    $c = imagecolorallocate($img,
      clamp(floor($color[0] + $d[0])),
      clamp(floor($color[1] + $d[1])),
      clamp(floor($color[2] + $d[2]))
    );
 
    $d = array($d[0] + $delta[0], $d[1] + $delta[1], $d[2] + $delta[2]);
  }
 
  imagepng($img, $filename);
  imagedestroy($img);
}

The code is straight forward. First, create the image via imagecreatetruecolor(). Then, starting with the starting color, draw a one pixel tall rectangle for each row of the image. The next row’s color is computed in each iteration by adding the accumulated delta to the starting color. Finally, output the image as a PNG via imagepng() and free the memory. The complete php source can be downloaded here.

Button Time

Once we have our perfect gradient engine in place, it’s time to make some perfect buttons. To achieve the standard glass button look-and-feel, I typically fuse two gradients together: light on the top, dark on the bottom.

Here are the two halves of a pretty red button, along with their starting color and deltas:

And the two commandline invocations of gradient.php to create the gradients:

php gradient.php 100x16 ff8080 -3,-3,-3 top.png
php gradient.php 100x16 d23c3c -3,-3,-3 bottom.png

If I want my buttons to be sexy, rounded corners are a must. My favorite photoshop trick to create multiple rounded buttons is to use a rounded alpha-transparent button with each gradient as a clipping mask. Using a clipping mask is a simple way to guarantee button geometry remains fixed while colors are changed.

Here is the layers pane showing the two gradients fused together and used as a clipping mask for the rounded alpha-transparent button:

The result is a horizontally stretchable gradient button, that doesn’t look half bad. See for yourself:

Custom UIButton

The final button asset can be used as desired, but here is a simple Objective-C example since I’ve been in iPhone world lately:

UIButton *btn = [UIButton buttonWithType:UIButtonTypeCustom];
[btn setFrame:CGRectMake(20, 20, 140, 32)];
[btn setBackgroundImage:[[UIImage imageNamed:@"btn-red.png"]
      stretchableImageWithLeftCapWidth:10.0
      topCapHeight:0.0] forState:UIControlStateNormal];
[btn setTitle:@"BUTTON" forState:UIControlStateNormal];
[btn setTitleColor:[UIColor whiteColor] forState:UIControlStateNormal];
[btn.titleLabel setFont:[UIFont boldSystemFontOfSize:14]];

Create a new UIButton of type UIButtonTypeCustom and then set the button skin as the backgroundImage. The horizontal stretchability is due to the stretchableImageWithLeftCapWidth and topCapHeight.

Here is a screenshot from the iPhone simulator showing the button in action:

Files

• gradient.php – the perfect gradient engine
• gradient-button.psd – the photoshop source for the red button image, including the rounded alpha-transparent button and fused red gradients
• btn-red.png – the red button image

But there is one trick for Inkscape: even though the coordinate origin on the Inkscape document is the normal cartesian origin in the bottom left and the y-axis points up, the SVG output always uses the upper left corner of the document as the origin and the y-axis points down (per the SVG Spec, § 7.3).

To demonstrate, I created a new document in Inkscape, set my dimensions to 500 x 500, and placed a simple path (which happens to be a square) in the upper left corner:

You can see by the rulers in Inkscape that the square’s origin is at (0,500).

If we save our square and examine the SVG output, we see:

<svg ...>
  <g ...>
    <path d="M 0,0 L 100,0 L 100,100 L 0,100 L 0,0 z" />
  </g>
</svg>

If we ignore everything in the file except the relevant path data, we can see the very first path command is M 0,0 which is path-speak for move to (0,0). This is exactly as expected from the SVG spec: upper left is the coordinate origin. The cartesian origin in Inkscape is bogus!

Next, we can just copy the path data from the SVG file and paste it into the data attribute of a Degrafa Path component.

<Degrafa:Path data="M 0,0 L 100,0 L 100,100 L 0,100 L 0,0 z">
    <Degrafa:fill>
        <Degrafa:SolidFill color="#EECCEE" />
    </Degrafa:fill>
    <Degrafa:stroke>
        <Degrafa:SolidStroke color="#FF00FF" weight="3" />
    </Degrafa:stroke>
</Degrafa:Path>

Give it a fill color and a stroke color, and we get a pretty purple square. Now I know my Degrafa Path component will have a square in the upper left, because I know my square was in the upper left in Inkscape. Nice and easy.

Files

• square.svg
• Square (download)

Plain Vanilla

I started with an unstyled, super vanilla WindowShade wrapping a List. And of course, I get this super-vanilla output:

shade 1 (view source enabled)

The only styling magic was to add padding="0" to the WindowShade to get the child List component to suck up to the bottom of the WindowShade button.

My First Attempt

In the next pass, I ditched the lame WindowShade button, and went with Flexlib’s CanvasButton, which contains a simple Label plus a CheckBox skinned with a plus or minus graphic. The code:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application
        xmlns:mx="http://www.adobe.com/2006/mxml"
        xmlns:flexlibContainer="flexlib.containers.*"
        xmlns:flexlibControl="flexlib.controls.*"
        viewSourceURL="srcview/index.html">
 
    <mx:Script>
    <![CDATA[
        [Bindable]
        private var goodies:Array = [
            { header:'Ice Cream', items:['Vanilla', 'Chocolate', 'Strawberry', 'Cookies & Cream'] },
            { header:'Candy', items:['Twix', 'Snickers', 'Fire Balls', 'Hot Tamales', 'Mike & Ikes', 'Pez'] },
            { header:'Cookies', items:['Chewy Chips Ahoy', 'Mint Milano', 'Oreo', 'Nutter Butter', 'Fig Newtons'] }];
    ]]>
    </mx:Script>
 
    <mx:Style source="style.css" />
 
    <mx:VBox width="140" styleName="container">
        <mx:Repeater id="r" dataProvider="{goodies}">
            <flexlibContainer:WindowShade width="100%" styleName="shade"
                    data="{r.currentItem.header}"
                    opened="{r.currentIndex == 0}">
                <flexlibContainer:headerRenderer>
                    <mx:Component>
                        <flexlibControl:CanvasButton width="100%" height="30" styleName="shadeBtn">
                            <mx:Script>
                            <![CDATA[
                                import flexlib.containers.WindowShade;
                            ]]>
                            </mx:Script>
 
                            <mx:Label id="header" top="3" left="4" text="{WindowShade(parent).data}" styleName="shadeHead"/>
                            <mx:CheckBox id="chk" top="9" right="6" selected="{WindowShade(parent).opened}" styleName="shadeChk"/>
                        </flexlibControl:CanvasButton>
                    </mx:Component>
                </flexlibContainer:headerRenderer>
 
                <mx:List width="100%" dataProvider="{r.currentItem.items}" rowCount="{r.currentItem.items.length}" styleName="shadeList"/>
            </flexlibContainer:WindowShade>
        </mx:Repeater>
    </mx:VBox>
</mx:Application>

After throwing in some colors from a sweet Kuler theme and embedding Helvetica, we get this:

shade 2 (view source enabled)

At this point, I was really happy with look and feel, but there we still a few minor issues with the CanvasButton header that needed to be fixed before declaring victory.

Fixups

First, I needed the rollover event to flow down to the checkbox, so it would correctly show the overSkin on mouse over. Second, I wanted a color change on the Label on rollover to provide better visual feedback to the user. And lastly, I wanted the entire CanvasButton header to be clickable, not just the label text or the checkbox graphic.

Focusing just on the modified CanvasButton code, used in the headerRendered:

<flexlibControl:CanvasButton width="100%" height="30" styleName="shadeBtn"
        rollOver="header.setStyle('color', 0xffffff); chk.dispatchEvent(event);"
        rollOut="header.setStyle('color', 0xcccccc); chk.dispatchEvent(event);">
    <mx:Script>
    <![CDATA[
        import flexlib.containers.WindowShade;
    ]]>
    </mx:Script>
 
    <mx:Label id="header" top="3" left="4" text="{WindowShade(parent).data}" styleName="shadeHead"/>
    <mx:CheckBox id="chk" top="9" right="6" selected="{WindowShade(parent).opened}" styleName="shadeChk"/>
    <mx:Canvas width="100%" height="100%" backgroundColor="#000000" backgroundAlpha="0" />
</flexlibControl:CanvasButton>

The final result, a nice styled WindowShade:

shade 3 (view source enabled)

I used the parent CanvasButton’s rollover event to set the child Label color and forward the event to the child CheckBox. To make the entire button clickable, I used one of my favorite Flex UI hacks: I added a space-filling transparent Canvas.

Comparison Shopping

And finally, a side-by-side comparison of all three WindowShade skins:

Update: See my Drawer Component in Flex 4 post for a custom collapsible drawer component written from scratch in Flex 4.

In The Red Corner

I’ll start with my simple two-column blog design that I like to call Circles of Doom. The original design was done in Inkscape, and assembled for the web using Blueprint CSS. You can read all the gory details of the design and assembly in a series of earlier posts: part 1, part 2, part 3, part 4.

Skipping right to the end result, you can view the final results here:

In The Blue Corner

Flex provides a lot of design leverage with its support for fills & strokes, gradients, rounded corners, and filters like drop shadow and glow. The original html design required the use of images to handle these features, but Flex’s CSS is powerful enough to handle everything with the exception of the blood red background circles.

The design architecture can be thought of as a simple three layer structure show here:

The bottom layer has the blood red background circle image. It is absolutely positioned vertically (y="-65") and horizontally centered (x="{(this.width - 950)/2}"). Like this:

<mx:Image source="@Embed(source='assets/circ.png')"
        x="{(this.width - 950)/2}" y="-65" />

The middle layer has the main box with rounded corners and a black glow. Like this:

<mx:VBox width="870" x="{(this.width - 870)/2}" y="130" styleName="body">
    <mx:filters>
        <mx:GlowFilter blurX="22" blurY="22" color="#111111" alpha="0.6" />
    </mx:filters>
</mx:VBox>

And the Flex CSS:

VBox.body {
	horizontalAlign: center;
	backgroundColor: #ffffff;
	borderStyle: solid;
	borderThickness: 10;
	borderColor: #886655;
	cornerRadius: 28;
	verticalGap: 10;
	paddingTop: 20; paddingBottom: 4;
}

And the top layer has the main content, sidebar & sidebar content, and footer. Like this:

<mx:Canvas width="790">
    <mx:Text text="main" width="590" styleName="contentTxt" />
 
    <mx:VBox width="190" x="600" styleName="sidebar">
        <mx:Text text="sidebar" width="100%" styleName="sidebarTxt" />
    </mx:VBox>
</mx:Canvas>
 
<mx:Text textg="footer" styleName="footerTxt" />

And the associated Flex CSS:

Text.contentTxt {
	fontFamily: Arial;
	fontSize: 12;
	fontWeight: normal;
	color: #000000;
}
 
VBox.sidebar {
	backgroundColor: #aa1100;
	borderStyle: solid;
	borderThickness: 2;
	borderColor: #ff2200;
	cornerRadius: 12;
	paddingLeft: 10; paddingRight: 10;
	paddingTop: 10; paddingBottom: 10;
}
 
Text.sidebarTxt {
	fontFamily: Arial;
	fontSize: 12;
	fontWeight: normal;
	color: #ffffff;
}
 
Text.footerTxt {
	fontFamily: Arial;
	fontSize: 10;
	fontWeight: normal;
	color: #886655;
}

The Result

Put it all together with some dummy Lorem ipsum text and you get a decent looking Flex blog design (just right-click, and select “view source” to see the code). It compares favorably to the original html design. The only obvious difference is the browser font rendering versus Flex’s font rendering.

The Files

• circles_of_doom_flex.tgz (view)

Sprites

It is fairly common to see sprites used in high performance web design. The Gmail team has a great blog post discussing various performance enhancements currently in use, including sprites. But for some reason, almost everyone thinks of sprites for icons and buttons. In my opinion, any time you can fuse two images into one, you’re making a “sprite” and you’re improving performance. Using a grid-based framework like Blueprint CSS tends create a lot of rectangular layout imagery, which are often ideally suited for fusing into a larger sprite.

The current web page has two candidates for spriting: the main header image can be fused to the footer, and the sidebar header to the sidebar footer. Just like this:

So the original circ-head.png and circ-foot.png are fused to create circ.png. Similarly, the sidebar header and footer are fused to create sidebar.png.

The original circ.css is simply modified with the new image filenames and a negative vertical offsets on the footer backgrounds. Here are the relevant parts of the new circ.css:

#header {
background:#111 url(img/circ.png) 0 0 no-repeat;
height:160px;
min-height:160px;
}
 
#footer {
background:#111 url(img/circ.png) 0 -160px no-repeat;
height:30px;
min-height:30px;
text-align:center;
}
 
#sidehead {
background:transparent url(img/sidebar.png) 0 0 no-repeat;
height:14px;
min-height:14px;
}
 
#sidefoot {
background:transparent url(img/sidebar.png) 0 -14px no-repeat;
height:14px;
min-height:14px;
}

Compression

Using OptiPNG is really easy. Just run it over a folder of PNGs, and it losslessly compresses what it can, and leaves the rest untouched. When I’m not using source control on a design, I’ll often perform the compression step exclusively on the server to keep things simple.

Here is a simple command to perform maximum compression of all the PNGs in a folder:

optipng -o7 *.png

Digging Deeper: I have noticed that OptiPNG, in it’s quest for maximum optimization, will sometimes alter the image type (either by reducing the bit depth or switching from full color to indexed color) in such a way as to make Photoshop very unhappy with the resulting image. In these cases, the GIMP is your friend.

The Results

We fused four images totaling 52552 bytes into two images totaling 52356 bytes. So we saved two whole HTTP requests and a meager 200 bytes. Not much to write home about (or even blog about), but hopefully it serves as a useful demonstration that design optimization is fairly simple. Next up, we’ll take our design and layout into Flex. What fun!

The Files

• circles_of_doom_v2.tgz (view)

Slice It

Before we get slice happy, we need to think. First, Blueprint is grid-based, so that means rectangles are good. And second, the default Blueprint container width is 950px. The defaults are intelligently chosen and have always worked great for me. By sticking with the defaults, we will get a 950px wide, centered, fixed-width site, which is exactly what we want.

We could get all clever and try to slice out just the circles as a background image, but that would force the top border to be a transparent PNG because of the shadow. Similarly, we could cut out all four rounded corners and all four edges of the sidebar, but that would force us to reassemble humpty dumpty with some fancy css and markup. In both cases, just say No! The simplest possible choice is to slice the entire header, the entire footer, and then a thin slice for the body that can be vertically tiled. Exactly like this:

And we get: the header, the background tile, and the footer. Slicing the sidebar in the exact same manner gives: sidebar header, sidebar background tile, and sidebar footer.

Code It

The original simple blog layout had four divs: header, content, sidebar, and footer. This is exactly want we want, but the original markup won’t exactly work, because the current design has a vertically-tiled background. The solution is simple – just wrap the content and sidebar inside a div with a bit of padding (via a prepend-2 and append-2). If we ignore the sidebar design for a moment, and just insert a placeholder, the markup is:

<div class="container">
  <div id="header" class="span-24">header</div>
 
  <div id="bg" class="prepend-2 span-20 append-2">
    <div id="content" class="span-15">content</div>
    <div id="sidebar" class="span-5 last">sidebar</div>
  </div>
 
  <div id="footer" class="span-24">footer</div>
</div>

That’s just beautiful Blueprint markup! Adding some simple css:

body {
background-color:#111;
}
 
#header {
background:#111 url(img/circ-head.png) 0 0 no-repeat;
height:160px;
min-height:160px;
}
 
#footer {
background:#111 url(img/circ-foot.png) 0 0 no-repeat;
height:30px;
min-height:30px;
text-align:center;
}
 
#bg {
background:#fff url(img/circ-bg.png) 0 0 repeat-y;
}

And that gives us Circles of Doom, version 0! View it, or download it. I’ve included the latest-and-greatest Blueprint CSS, which is v0.8 at the time of writing. I’ve chosen to enforce the vertical height of the header and footer via height and min-height which seems to work fine in Firefox, Safari, and IE7.

Sidebar Me

Since the sidebar graphic was sliced in the exact same manner as the body graphic, we just add the exact same markup to the sidebar div – header, bg, and footer.

<div id="sidebar" class="span-5 last">
  <div id="sidehead" class="span-5"><!-- sidebar header --></div>
  <div id="sidebg" class="span-5">sidebar content</div>
  <div id="sidefoot" class="span-5"><!-- sidebar footer --></div>
</div>

Style it like this:

#sidehead {
background:transparent url(img/sidebar-head.png) 0 0 no-repeat;
height:14px;
min-height:14px;
}
 
#sidefoot {
background:transparent url(img/sidebar-foot.png) 0 0 no-repeat;
height:14px;
min-height:14px;
}
 
#sidebg {
background:transparent url(img/sidebar-bg.png) 0 0 repeat-y;
}

Putting everything together with some dummy Lorem Ipsum text gives us Circles of Doom, version 1! View it, or download it.

Debug It

Lorem Ipsum text is the basic unit testing for HTML+CSS. I always fill out every content div with some dummy text, just to see what breaks. This time around, I noticed the sidebar content was touching the edges. I decided against adding a prepend-1 and append-1 because that’s too much padding. Instead, I thought I might just add some padding to sidebg, but this is bad, bad, bad! You can not add padding or margins to a Blueprint node, which sidebg clearly is because of the class="span-5". I could add another div inside sidebg, but that seemed like too much markup. So, I took the easy way out and just padded the known sidebar content markup (in this case, just p and h3).

#sidebar h3, #sidebar p {
color:#fff;
padding:0 10px;
}

Digging Deeper: Blueprint CSS uses margin and padding to create the grid. Thus it should have been obvious to me that you can NOT add margins or padding to a Blueprint element (any markup element with a Blueprint grid class). Alas, it was not immediately obvious, but I was able to catch my mistake during debugging.

And that’s it for the visual aspect of Circles of Doom. Next, I’ll cover web design optimization.

The Files

• circles_of_doom_v0.tgz (view)
• circles_of_doom_v1.tgz (view)

On this blog, I started with robots, which quickly lead to gears and mechanics. For this post, I started with circles. Actually, I started with Ironman’s HUD. The whole movie was super cool, but the HUD was the best. And the HUD had all this motion and targeting, and that’s what got me to circles. So that’s the theme. I already know I’m going to apply this theme to a simple grid-based blog layer that I discussed earlier.

Palette

After the theme, I worked on the color palette. I’ve used Kuler in the past to build out a couple of palettes, but this time I just jumped into Inkscape and started messing around. I came up with a nice blood red and black palette.

Circles

Now that I have a palette, I shift my design focus back to circles. It’s not just gonna be “Dot, dot, dot” as my daughter likes to say, so it’s back to Inkscape. Here’s the result:

Layout

Not much left but the real work – make a cool blog design with circles plus some pretty colors. I know my layout, so once again it’s back to Inkscape. There is a nice Inkscape template generator for Blueprint CSS grid layouts. Choosing which colors go where isn’t too bad, because I love dark text on white for blogs. Following that decision, I go with lots of circles in the header in blood red, over a black background. We know the main content will be white with black text, so I decide to make the sidebar really stand out with a bold blood red.

The circles in the header are really easy, I just pick random sizes and put them in random locations. Darker usually means further away, so I just reduce the opacity to let more black through. I use a rounded rectangle with a thick stroke for the main content area. I also add a black shadow around the entire content area to highlight the content. The finished design is here, and I’m calling it Circles Of Doom. Here is a closeup of the header:

Next, we slice and dice…

Files

• palette.svg
• circles.svg
• circles-of-doom.svg