100+ WordPress Plugins

Mashable has published two essential lists for anyone working with WordPress. I'm currently working on a project involving WordPress. I've spent many hours researching WordPress tools for specific purposes. But there are many plugins on these lists that I hadn't found but really need. If you need a plugin then start your search with these lists :

• 50+ WordPress Plugins for Multimedia

• 50+ Tools For The WordPress Admin

• 30+ WordPress Plugins To Get More Blog Readers

• 30+ WordPress 3-Column Themes
• 30+ WordPress 2-Column Themes
• 30+ WordPress Plugins for Statistics

"Geeking Out" On Fireworks Flex Components

I've been a regular reader of Alan Musselman's blog for as long as I can remember. If you are at all interested in using Fireworks then Alan is the man to read. Even if it's only to discover all the other great blogs he mentions. So I was very excited to read his blog today and discover his post was about this blog. Specifically his post relates to my ongoing experiements with building Fireworks Flex Components (FFC's) with links to four of my posts on this topic. Below is the complete list of posts on FFC's :

• Fireworks CS3 : Creating Flex Symbols

• Fireworks Flex Components : Extended

• Fireworks : Flex Style Explorer

• Fireworks Flex Components : Label

• FFC : LinkButton (Managing State)

• FFC : :LinkButton (flexClassDefinition)

• FFC : LinkButton - Tidying Up
  

Flex LinkButton : Background Color

This post is a variation on an earlier post where I talked about having no background on Flex's LinkButton rollover state. This post relates to a question I saw on a forum about how to set the color of the LinkButton's background in the up state (no rollover). The LinkButton by default sets it's background transparent when there is no user interaction. There isn't any style attribute you can use to directly change this behaviour. To override this behaviour you need to set a skin :

 LinkButton {
   upSkin:Embed("up_skin.png");
   overSkin:Embed("over_skin.png");
   downSkin:Embed("down_skin.png");
}

In this example I'm using a graphic. But you could also use a Flash symbol (see earlier post). The behavior of the LinkButton's label is unchanged by skinning the component in this way making this quite a useful approach. But if you want your LinkButton to have a background and you set that with a skin then you might want to consider if it's not really a Button that you need. The Button provides more style options than the LinkButton and may therefore be easier for this sort of use.

Web 2.0 Shopping Spree Goes Mobile

Since the iPhone's release there has been at least a post a day of Web 2.0 services releasing iPhone applications. In fact, throughout the year there has been a steady trickle of announcements about this and that service making deals or releases relating to mobile access. We've also seen near daily announcements of Web 2.0 acquisitions by Google, Yahoo and Microsoft (to name a few). But one thing I don't remember seeing (please correct me if I'm wrong) is mobile phone companies buying Web 2.0 companies. Which is why I was interested to read that Nokia had purchased media sharing site Twango. "The plan is to provide a seamless integration of Twango on both the Internet and on your cell phone." It seems natural that as mobile phone companies look towards better integration with the web that they would want to get involved in developing services. But if mobile companies are going to join the Web 2.0 shopping spree it would seem the buying bubble just got a whole lot bigger.

Adobe CS3 : Install Headache

I've just spent a good part of the last 24 hours installing Adobe CS3 Web Premium.  Sure I didn't spend the whole time on the install.  But I was doing something towards it for most of my waking hours.  I have never had so much trouble installing the web studio before.  Perhaps the most disappointing part was that I couldn't use my serial number with the trial software I installed last month.  Consequently I had to uninstall every application before trying to install the suite (each application took 20 minutes to uninstall).  This was a real headache as I don't have a DVD drive and the suite only comes on DVD.  This is clearly mentioned in the system requirements so I can't grumble here.  But it wasn't an unreasonable assumption that I could use my serial number to activate the trial software.  In the end I had to transfer the 2GB of install onto a Flash drive and install from there (I wasted quite a bit of time exploring other options before I found this solution; which required the purchase of a 2GB+ Flash drive).

I made one big mistake while uninstalling the Flash trial; I didn't uninstall the Flash player and plugin because I needed them for Flex. When I ran the installer I couldn't install Flash because it said I already had Flash (because I hadn't uninstalled the player and plugin).  In the end it took another 20 minutes to uninstall the two remaining Flash components before I could re-run the installer.

The final small obstacle was that I couldn't activate the software without disabling my firewall.  This wasn't a big thing (though I didn't feel comfortable about needing to disable my firewall). 

My question at the end of all this is why does it need to be so difficult (and I know from searching that my experience is mild compared to some).  Most of the issues seem to come from an attempt to make the different applications interact more seamlessly.  Most of the install (and uninstall) time is spent dealing with "shared components".   But I'd give that up in a second if I was given some options about how I want to install and use the software.  I rarely need my applications to work hand in hand.  What I want is for them to start quickly, run efficiently and take care of the job at hand with as little fuss as possible so I can move onto to the next part of the workflow.  I'm sure I'm not speaking for everyone.  But at the same time I'm sure I'm not the only user who feels this way.

Web 2.0 Trendmap using Web 1.0 approach

Over the last few days I've recieved emails and seen posts about the Information Architects 2007 Web Trend Map. The map attempts to map out current web trends using the Tokyo subway map as the basis for design. Unlike a few commentators at TechCrunch I always find these things thought provoking. But I couldn't help but feel that some of the data was probably out of date before the site went live. For example, Last FM and Pandora both show nice conditions ahead. But recent discussions about royalty rates tell a very different story. I don't think you'd have to look too closely at the map to find many similar anomolies. The reason for this problem is that the approach to the map is too Web 1.0. The data is static and must await a process of review and revision before changes can be made. Compare that to a web 2.0 approach were the data is harvested from a web service or user contributions (or a combination of both). Obviously the design needs to be fairly static. It would be difficult to get the map to redraw itself based on dynamic data. But there is no reason that each node and it's icons couldn't be dynamically generated. This would remove the irony of having a static image attempting to map the dynamic culture of the contemporary web.

Position Vacant : Adobe Competitor Required

It's taken a while to sink in. But the biggest disappointment for me post ReMIX is that Expression and Silverlight are light years away from offering any serious competition to Adobe's Dreamweaver/Flash/Flex ( see Expression : Dreamweaver Cloned and ReMIX : Silverlight Surprises) . I guess I didn't really expect Microsoft to offer a genuine challenge in this arena. It's not something they have ever been good at. But I think it's very important that someone does offer an alternative. It's not that I don't love what Adobe has been doing. But monopolies are always bad. Adobe don't quite have a monopoly and it is hard to use that term when Microsoft is the competition.

I find myself thinking over Chafic Kazoum's perspective ; that Microsoft isn't really interested in competing with Adobe. They are just offering their developers an alternative to discourage wandering eyes. In other words the semblance of competition will be enough to satisfy most Microsoft developers. I was sceptical when I first read this view. But my experience at ReMIX suggests it has merit.

But that doesn't help us. We need competition. Competition fosters innovation and competition keeps software prices down. There are options out there (i.e OpenLaszlo) but they are too dispersed and too small to have a real impact. Perhaps what we need is for someone to start buying up all the Adobe competitors to harness their combined potential.

Victorian Adobe User Group : July Meeting

The next meeting of the Victorian Adobe User Group will take place this coming Thursday from 6 PM.

For the main presentation Brian Chau from Adobe will be talking about Adobe Fireworks CS3/Flex integration and the new Fireworks Photo Gallery feature. Brian is always a lively and informative presenter. Fireworks has always been an undervalued application and these new features extend it's value to a whole new group of users.

We'll also be looking at part one of a video tutorial called Actionscript 3 Basics from Cartoon Smart. Cartoon Smart is a great resource for learning about Flash (actionscript and animation) and Web Design. They have very kindly provided a couple of their video tutorials for use by the user group. With the introduction of Actionscript 3 into Flash CS3 this is a very timely presentation. I've always felt that one of the biggest hurdles to moving to Flex development isn't Flex itself but rather the change to AS3.

If you're in the state, available and interested it will be great to see you there. The venue has a limited window of easy access so make sure you check out the access details (note : site still branded as MUV) before coming.

FFC : LinkButton - Tidying Up

This is my third post looking at creating a LinkButton Fireworks Flex Component (FFC). In the first post we looked at using a state property to manage the appearance for different states of the FFC within Fireworks. This state property created a problem with the exported MXML by introducing an invalid property so in the second post we talked about using flexClassDefinition to get more control over the exported MXML. In this post we'll look at some of the small details that we missed in those posts.

Firstly, let's look at adding a property to manage if the LinkButton is enabled. This property is included in the default FFC's and I'm aiming to maintain consistency with those as much as possible. We actually need two properties; enabled (a Boolean) and disabledColor (a Color). The disabledColor effects the text color when the LinkButton is disabled. All that's required to make this work is the addition of an additional if statement within applyCurrentValues :

if(enabled)
{
switch (state)
{
//states managed here
}
}
else
{
label_obj.pathAttributes.fillColor = values[13].value;
bg_obj.visible = false;
}

The second missing detail relates to a group of three properties that are relatively easy to implement ; fontWeight, fontStyle, textDecoration. Each of these properties have two potential states (which vary for each). So the best way to handle this in the properties is with a ComboBox :

values.push({ name:"fontWeight", type:"ComboBox", value:"bold,normal,bold" });
values.push({ name:"fontStyle", type:"ComboBox", value:"normal,normal,italic" });
values.push({ name:"textDecoration",type:"ComboBox", value:"normal,normal,underline" });

This creates a slight complication in applyCurrentValues because in Fireworks each of these settings is actually a Boolean so we need to do a simple if else statement for each property :

if(values[9].value.split(",")[0] == "bold")
{
label_obj.bold = true;
}
else
{
label_obj.bold = false;
}

if(values[10].value.split(",")[0] == "italic")
{
label_obj.italic = true;
}
else
{
label_obj.italic = false;
}

if(values[11].value.split(",")[0] == "underline")
{
label_obj.underline = true;
}
else
{
label_obj.underline = false;
}

Adding these also creates a problem in the export. Because it outputs all the options to the MXML rather than just the selected one. I could make them all Text but then you'd need to know the correct value to type in. Which could lead to all sorts of problems. As is all you need to do is to remove the unwanted options from the MXML. I'm keen to fix this but I haven't found an answer as yet. With some luck a kind reader will emerge with the solution.

There are four other styles that could be added to our LinkButton FFC ; cornerRadius, paddingLeft, paddingRight, letterSpacing. They could be easily added to the properties list. But I've yet to find a way to update the FFC to display these styles. Everything else we've added is able to be visualised and I don't see any value in having the styles included if they can't be displayed. The whole point is to be able to create a document that can be used to create a design and to output a working Flex file. So for now I've left these styles out until I can find a way to get them working.

If you want to use my LinkButton FFC or use the files as the basis for your own FFC's or you want to experiment with the missing details you can get the files here.

FFC : :LinkButton (flexClassDefinition)

In my last post we talked about creating a LinkButton Fireworks Flex Component (FFC). By the time we finished we had a component that could update and export the LinkButton's different states. We could also control the label, font and fontSize. As you may remember there was a problem in the exported MXML. There isn't a state property for LinkButton and consequently Flex Builder correctly flagged an error.

We can get more control over what is exported to MXML by using the flexClassDefinition. The flexClassDefinition is an object with some useful properties that can be added to customData. The basics looks like this:

var definitionObject = new Object();
Widget.elem.customData["flexClassDefinition"] = definitionObject;

You won't see this defined in the default FFC's (e.g Button) as this is handled by the exporter. But for our custom components this mechanism is needed. I'm not going to talk about all the available properties (because there is an article that does a much better job than I ever will) only those we need. Let's start by removing 'state' from the exported MXML. To do this we define the attributes we wanted exported:

definitionObject.defaultProperties = ["id","x", "y", "width", "height"];
definitionObject.attributeProperties = ["label", "enabled"]; 

The defaultProperties is an array of attributes that we haven't defined as properties and that we want to have included. The array can also include; alpha, source and styleName. By not including these within defaultProperties they won't be included in the export. If one of the included defaultProperties isn't required (for example if we don't change the FFC's opacity it's alpha attribute isn't required) it isn't exported.

The attributeProperties is an array of the properties that we've defined that we want included. By not including 'state' in this array then 'state' isn't included in the exported attributes. You'll notice I've kept this list short and consequently none of the style properties would be exported. The reason is that I actually want them defined as a style. In fact ideally I'd like to have one style defined for all LinkButtons if they look the same and to use custom styles if they are different. I want the same styling intelligence we get using Text to create Labels (see FFC : Label for more on this). We can get this exact behaviour by defining styleProperties :

definitionObject.styleProperties = ["color","textRollOverColor",
       "textSelectedColor","rollOverColor",
       "selectionColor","fontFamily",
       "fontSize","disabledColor"];

Defining styleProperties like this earns us the following style definition in the exported MXML :

<mx:Style>
 LinkButton {
  disabledColor:#AAB3B3;
  fontSize:11;
  fontFamily:Verdana;
  selectionColor:#7FCDFE;
  rollOverColor:#AADEFF;
  textSelectedColor:#2B333C;
  textRollOverColor:#2B333C;
  color:#0B333C;
 }
</mx:Style>

That brings us pretty close to a fully functional LinkButton FFC. There are still a few things that can be added and a few problems to be solved. But let's talk about them next time. Until then you might want to take a look at the source files.

FFC : LinkButton (Managing State)

A little while ago I wrote a few posts relating to creating a simple HRule Fireworks Flex Component (FFC). I chose the HRule because it wasn't interactive and hence relatively simple to implement. But now I'd like to move on and do something a little bit more interactive and to tackle some of the issues involved. Looking around I settled on the LinkButton. LinkButtons display a label with no background in the normal state. On rollover the background is displayed and the label changes color. On mouseDown the backround color changes and the label color could change (the default is that the rollover and selected label colors are the same).

Looking at the Button component from the Flex Components you'll notice a State property with three options ; Up, Over and Down. In the Button FFC changing the textRolloverColor and then selecting the Over state you'll see the FFC update to display the new textRolloverColor. This State property allows us to preview the style changes that relate to different states of an interactive component. Adding this State property to the setDefaultValues function is our first job when creating an interactive component. It looks like this :

values.push({ name:"State",type:"ComboBox", value:"Up,Up,Over,Down" });

Within applyCurrentValues we'll need to get the current selection of this property:

var state   = values[0].value.split(",")[0];

Then use the value of state to decide what values to apply. Before doing that lets take a look at the structure of LinkButton.graphic.png. Like the HRule it's very simple. There is a text field named 'label' and a rectangle named 'bg'. For each of the selected states we'll need to update the color of 'label' and the color and visibility of 'bg'. To do this we need to define 5 properties within setDefaultValues ;

values.push({ name:"color", type:"color", value:"#0B333C" });
values.push({ name:"textRollOverColor", type:"color", value:"#2B333C" });
values.push({ name:"textSelectedColor", type:"color", value:"#2B333C" });
values.push({ name:"rollOverColor", type:"color", value:"#AADEFF" });
values.push({ name:"selectionColor", type:"color", value:"#7FCDFE" });

Here's the code from applyCurrentValues that uses the current state to set these values;

var state   = values[0].value.split(",")[0];

var label_obj = Widget.GetObjectByName("label");
var bg_obj = Widget.GetObjectByName("bg");

switch (state)
{
 case "Up"  :
  label_obj.pathAttributes.fillColor = values[2].value;
  bg_obj.visible = false;
 break;
 case "Over":
  label_obj.pathAttributes.fillColor = values[3].value;
  bg_obj.pathAttributes.fillColor = values[5].value;
  bg_obj.visible = true;
 break;
 case "Down":
  label_obj.pathAttributes.fillColor = values[4].value;
  bg_obj.pathAttributes.fillColor = values[6].value;
  bg_obj.visible = true;
 break;
}

As you probably spotted the tricky bit is getting the value of state. But this line is copied straight out of the Button component so the only credit I get is for being smart enough to look at those components. The rest is a matter of changing the fillColor for the 'label' and 'bg' to the relevant colors and setting the visible property of 'bg'. Set visible to false for the 'Up' state and true for the others.

There are a few other relevant properties/styles we can easily change. The simplest properties are the label property (controls the text visible on the LinkButton), font and fontSize :

//setDefaultValues after state
values.push({ name:"label",type:"Text",value:"Button"});
//setDefaultValues after selectionColor
values.push({ name:"fontFamily", type:"font", value:"Verdana" });
values.push({ name:"fontSize", type:"Text", value:"11" });

//applyCurrentValues after state switch statement
label_obj.textChars = values[1].value;
label_obj.font = values[7].value;
label_obj.fontsize = Number(values[8].value);

All this works nicely within Fireworks but there is a problem that you may have spotted. When we export to MXML Flex Builder will display an error because 'state' is not a valid attribute for the LinkButton (all Fireworks properties are added as attributes). For now we can simply remove the state attribute. But to fix the export we need to talk about "flexClassDefinition". Let's save that till the next post. In the meantime you can look ahead by downloading the source files.

BlueDot Makeover

I've been using BlueDot since the start of the year for the purpose of managing my bookmarks. Originally I'd tried del.icio.us. But BlueDot had some additional features that I found handy. Like with any service there are always improvements that could be made. Hence it was a pleasant surprise when a page refresh revealed a BlueDot home page makeover. BlueDot's design was always better than del.icio.us but these changes make it even more so. The improvements are simple; near the top of the page there are now three tabs. One tab each for Dots, Tags and Favorites. Placing Favorites on a tab has allowed them to remove it from what was an increasingly busy sidebar. Tags remain on the sidebar but having a tab makes them more readily accessible. It's only the most popular Tags but thats fine especially when they each have a graphic to simplify selection. This Tag page existed before it's just that it was too hard to find to be useful. The other obvious difference is the addition of a slogan (Stuff you care about) to the logo. As I said the differences are simple. But they are improvements and when you are a regular visitor then any improvement is a big one.

Support Your Local Adobe User Group

Leif Wells has just posted defending Adobe User Groups. It is written in response to a flame he read on digg. But I wanted to highlight this :

'The user group in your area has been created and organized by people like me who truly love what people like you do with Adobe's products. By not participating in you local user group, for any reason, you miss out on spending time with people from your own community who could use your support. You also miss out on spending time with people from whom you could draw support and inspiration.'

I have an obvious interest as a member of the Victorian Adobe User Group (site branded : MUV). But I am a member because I agree with Leif's sentiments. If you do too then why not find out about your nearest user group. For Victorians we meet on the 3rd Thursday of every month and you can get email reminders by becoming a member.

Fireworks Flex Components : Label

One thing I noticed the other week and have only just had a chance to invesitgate further is that Fireworks doesn't have a Label or a Text component. There is a good reason for this; it doesn't need them. If I draw a rectangle path on the stage and export it the rectangle is defined as an Image and a gif is exported with the MXML file to fill that position. But try placing a piece of text onto the stage and then exporting to MXML. Fireworks will define the Text within MXML as a Label. It will also define a Label style to define the appearance of the Label. Even more interesting if you add a second seperate piece of Text with some difference in appearance it will define two custom styles to define the appearance of the two Labels and add the styleName attribute to the Label. There is one final piece of intelligence that ensures the Fireworks to Flex workflow is spot on. Add a multi-line piece of Text to the stage and export. What you'll notice is that the multi-line text is exported as a Text component and that a Text style is defined.

This capability to appropriately export Text into mxml isn't mentioned in any documentation I can find and isn't immediately obvious when you look at the Flex Components. But it certainly is very useful once you know about it.

Fireworks : Flex Style Explorer

A while ago I saw this article on Flex styling in Fireworks CS3. I didn't write about it at the time because I didn't have access to CS3 and couldn't really test things out. But in my continuing search for the best way to integrate Fireworks into the Flex development workflow I've just taken another look. The real gem in this article is the Flex Styles Explorer. I've been using the online version of this tool from the day it first appeared and I use it often. It's a genuine time saver for styling Flex components. The Fireworks version of the tool gives easy access to the tool offline as well as allowing you to copy the generated css for use in Flex. It doesn't apply the styles to the Fireworks Flex Components so you won't be able to completely reproduce the design in Fireworks. But it provides a path for getting it quickly into Flex and anything that makes life easier is a good thing to me.

Adobe CS3 : Suite Inconsistencies

One the new features that I'm loving in Photoshop is the new compact panel system. When not in use panels appear as a cluster of grouped buttons on the right hand edge of the interface. Selecting a panels button (i.e Layers) opens that panel for use. Selecting a different panel will close the current one. It also seems to have enough intelligence to know when you're likely to want to keep it open. So far I haven't found any annoyances using this system in Photoshop. In fact more than once I've been heard to exclaim loudly how much I love it.

The same system is used in Flash and Illustrator. But hasn't been added to Fireworks and Dreamweaver. This adds a significant inconsistency between applications within the suite. Sure this is a minor gripe. Theses applications were originally released by two companies in two completely unrelated suites. So it's not a surprise that both suites of software aren't fully integrated in this first post merger release. But that doesn't mean I can't be working in Fireworks wishing I had that great compact panel system that they have in Photoshop.

The one post-Macromedia product that does have the compact menu is Flash. But the system is no where near as stable and intelligent as the Photoshop implementation. The problem seems to mostly effect the larger panels like Help and Actions. The Help panel in particular seems to be very flakey in it's behaviour. I guess we'll need to wait for CS4 to see these things sorted out.

Lightroom Painter : Odd metaphor but very useful

I've started using Adobe Lightroom for a photography project at work. I started a few weeks ago as the number of photos I needed to manage for the project grew and grew. It didn't take me long to get my head around Lightroom's structure and to find it quite indispensible. It wasn't perfect but the issues were small niggles rather than real issues. So I was very interested to see what they had changed with the 1.1 update that was released last week. The changes were mostly subtle but all were welcome. But there was one that took me a little while to get my head around ; the Painter. When viewing a collection or folder and you're in grid view a spray can icon appears in the grid tool bar. The spray can has a vertical tag icon and the tooltip says "Painter". On rollover we see some dots emerge from the cans nozzle. So you select the spray can and it comes off the tool bar (there is a darker circle showing where it belongs). Clicking on the circle puts it back. But you find yourself wondering what the hell does it paint. With the tool selected a partial answer is evident because you now see "Paint : Keywords" with a text field next to the Painters circle. It turns out you can type keywords in the text field and then "paint" them onto multiple images. In fact successive paints will toggle the keyword (i.e if the keyword already exist it is removed. Nice :o)

But wait there's more! It turns out Keywords is one option of many. You could also choose to "Paint" a :

• Label
• Flag
• Rating
• Metadata
• Settings
• Rotation

Settings is pretty interesting as it lets you paint on one of the presets (i.e Sepia tone, Grayscale, sharpen) or your own user defined settings. Rotation is sort of fun as you watch a whole row of images rotate clockwise.

It still feels sort of odd to be "painting" on keywords or a rotation. But ignoring the metaphor it's a very useful tool if you use any of these attributes. I use keywords to order my collections and I use ratings when working out image preferences. The keywords I use in bulk. Though ratings I tend to use on one image at a time. But I'm sure we all have very different workflows so this will suit different users in different ways.

Fireworks Flex Components : Extended

In a recent post I was looking at the steps required to create a simple HRule FFC (Fireworks Flex Component). You may remember that I included a property for defining the strokeWidth style but I didn't go so far as to actually get the FFC to update it's appearance because I wanted to keep the post simple. Over the last couple of days I've been working towards implementing this last element. But it turned out to be a little more difficult than I expected and required a few changes to my original FFC to make it work. The aim of this post is to look at these changes and what was required to make this work.

Firstly, let me talk about the reason I had trouble finding what in the end was quite a simple solution. With Fireworks javascript the best way to find out whats going on is to select the step you are interested in from the history panel and then select "copy steps" from the panels menu. This copies the relevant javascript to the clipboard. But that doesn't help us with our FFC's because the 'Symbol Properties' panel talks to the FFC using the Widget object. This interface works somewhat differently from the main API. The second reason this proved difficult is that none of the existing FFC's have an example of changing an object size within the FFC. In the end I found myself hunting through "Adobe Fireworks CS3 - Extending Fireworks" to find the answers I need (search for Widget and pathAttributes).

So firstly lets take a look at what changes we need to make to the HRule.graphic file. It's quite simple; we just need to replace our two paths with lines and then rename them as 'line' and 'shadow'. You'll then need to confirm they are correctly positioned. For some odd reason I found I needed to place the shadow 2 pixels below the line. These were the only changes I needed to make to the graphic.

Next open up the HRule.jsf file. The first change I made was within 'setDefaultValues' where we change the strokeWidth properties type from being a number to "Text". I'm not sure why this was necessary but a couple of issues disappeared when I did. Most of the real changes occured in 'applyCurrentValues' so let's have a look at the whole function :

function applyCurrentValues()
{
 var values = Widget.elem.customData["currentValues"];
 var w = Number(values[1].value);

 var line_obj = Widget.GetObjectByName("line");
 
 line_obj.pathAttributes.brushColor = values[0].value;
 line_obj.pathAttributes.brush.diameter = w;
 
 var shadow_obj = Widget.GetObjectByName("shadow");
 
 shadow_obj.pathAttributes.brushColor = values[2].value;
 shadow_obj.pathAttributes.brush.diameter = w;
}

The first line remains the same, but note the second line where we pick up the value for strokeWidth and convert it to a number. Now there are two blocks of three lines one for 'line' and one for 'shadow'. Both blocks do exactly the same thing but to a different path. The first line of each stores a reference to the object within a variable. This saves us from writing Widget.GetObjectByName("objectName") on the next two lines of eaach block. Those two lines are probably self explanatory but let's take a quick look. Both use 'pathAttributes' to change properties of the path. The first refernces brushColor to change the color of the paths stroke. For 'line' it gets changed to strokeColor. For 'shadow' it gets changed to the shadowColor. On the second line of each we set the brush.diameter to the strokeWidth.

That's it! You'll need to reload the "Common Symbols" panel and then drag the HRule component onto the stage. But now any changes we make in 'Symbol Properties' will be reflected within Fireworks as well as being exported into the MXML. From here we can very easily make a VRule FFC simply by saving HRule.graphic.png as VRule.graphic.png and rotating the lines. Then saving HRule.jsf as VRule.jsf and changing HRule to VRule on the first line of 'setDefaultValues'. Too easy. There's still quite a few things to work out before we could improve the existing FFC's or to make a full set. But with what we know now we could make a fairly complete set.