More Degrafa skins

, ,

Before I dig too deep trying to create a Degrafa Skin Explorer (the idea) as an evolution of the Degrafa Button Explorer, I thought it would be a good idea to spend some more time with some basic Degrafa skinning. I managed to create a few button skins previously, but this time around I wanted something more involved.


First, I built out a pair of ButtonBar skins (view source enabled):

Flash is required. Get it here!

Next, I augmented the my basic ButtonBar skins with the various required selected skins (selectedUpSkin, selectedDownSkin, etc.) to create a pair of ToggleButtonBar skins (view source enabled):

Flash is required. Get it here!
iPhone Theme

Lastly, I dissected the iPhone-esque theme sample from the Degrafa Samples page, and created my own bastardized iPhone theme. I factored out a theme color from each component into a CSS style called mainColor to allow the skin to be tweaked. Check it out (view source enabled):

Flash is required. Get it here!

I learned a couple of things during my skinning exercise, but probably the most important came to me in an amazing “A-Duh” moment: Degrafa is really powerful. This is probably the same as saying MXML is a high-level language with a lot of leverage, but the Degrafa team has done a great job bringing this leverage to bear on skinning and graphics in Flex. At this point, I find it hard to imagine creating a style without it.

Secondly, semantic naming is a must inside a stateful skin. So, I replaced any names like darkFill or lightStroke, with nice semantic names like overFill and selectedStroke. So if I look at a chunk of code like this:

<State name="downSkin">
    <SetProperty target="{rect}" name="fill" value="{overFill}" />

I can immediately know that my downSkin state is using a fill from my overSkin state, and probably implies the states are the same.

Lastly, always resist the temptation to re-use/re-purpose the CSS style from the underlying component in a skin. For example, the iPhone theme above uses a theme color which I intentionally named mainColor. I could easily have used Button’s aptly-named themeColor style (inherited down from UIComponent). But this would dangerously overload the meaning of themeColor, because while it normally controls the Button’s border color it would now control the body color in my iPhone button skin.





Great point about MXML…. MXML truly does have a lot of leverage, and can really serve as a foundation for creating many different domain specific languages. Someone said the “heart and soul” of Flex is MXML and Binding, and I couldn’t agree more. It is amazingly powerful.



I’d say that MXML is a decent DSL host, but most of its leverage comes its hierarchical nature. Thankfully, Degrafa uses everything MXML has to offer to create its powerful syntax.

To me, Ruby is the best DSL host language that’s in common use. But Bill Venners has a good Ruby vs. Scala post that details Scala’s threat to the king.




Great examples. Any idea how you could change the button color (or button backgroundColor) in a ButtonBar at runtime?




I sort of answered my own question. What I did was loop through all the children of the ButtonBar and use setStyle() on each child. Maybe there’s an easier way?



@Andrew: Yes, using setStyle() is your friend when styling at runtime.

© 2014