Skinning Minimal Comps

A lot of people have asked, and continue to ask how to skin minimal comps.

Short story, long story, what you can do.

Short story: you can’t.

Long story: Minimal Comps were designed to be minimal. Mostly for use in prototypes and experiments. Their visual UI is hard coded and skinning was never, ever part of the design consideration. In fact, the opposite: skinning was specifically and with malice aforethought left out. There are a few reasons why this is the case.

First, the technical reasons. At risk of repeating myself, they are minimal. This means they are small and light weight and (hopefully) exceedingly simple to use. Allowing for skinning adds a surprising amount of complexity. Every component and every sub-part of every component needs to have a replaceable way of drawing itself. It winds up as a whole architecture in itself. All this adds file size, complexity, potential bugs, and learning curve.

Also, if I added some kind of minimal skinning capabilities, it would not be enough for many users. They would complain that it does not work the way it should, it is not flexible enough, it doesn’t do X, Y, or Z, etc. It would wind up consuming more time and energy than I want to spend on it. Additionally, skinning would add a whole other API to the components beyond their functionality. This adds to the learning curve.

Finally, if you look at the architecture of the components, it is exceedingly flat. It is distinctly under-architected. If you examine all the classes that make up the components, there are very, very few that are not actual component classes in themselves. There is the Component class, which is the underlying base class for all components, Style, which contains some static color values, and Slider and UISlider, which are base classes for their vertical and horizontal subclasses. Other than that, each and every class in the package corresponds to exactly one component. There is some degree of inheritance and composition going on with the components themselves, but overall, there are no extraneous classes. I conceive that enabling skinning in any kind of useful, flexible way could add a significant amount of additional classes that would have to be compiled into every single class just to enable skinning, whether it was used or not.

Then there are the more… I don’t know… not technical but… theoretical(?) reasons. Personally, I just feel that if you get to the point in a project where you need to skin these things, that should be a signal to you that the project has crossed that line between an experimental/prototype/minimalcomp-type project, and a real project that needs real, non-minimal, UI components. I’m honored that so many people like the components enough that they want to use them in larger projects where they would need to be skinned. But I honestly feel that you would be better off at a certain point looking at other, more skinnable components. There’s Flex, which brings lots to the table and tons of customizability, and the CS4 components, which are easy to skin and style. Then there are plenty of 3rd party components sets. One to check out is my former coworker Ash’s Razor Component Framework.

The long and the short of it is that I have no intention of adding skinning capabilities to the components at a core level. It has not been and is not any kind of priority and I don’t foresee it becoming one.

What you can do: OK, take a look at the source. Each component has a draw method. Theoretically, this is where most of the visual UI of each component is created and updated. Draw is called whenever the component is resized or has anything done to it that would change its layout or appearance. If you want to skin a component, this is the stuff you need to change. You can extend the component class of your choice and override its draw method to do whatever you want:

[as3]public class SkinnedVSlider extends VSlider
{
public override function draw():void
{
// do your own drawing here.
}
}[/as3]

I’m not saying this is necessarily going to be smooth and easy. Actually, if you look at Slider.draw, you’ll see it calls drawBack and then drawHandle. So, you could either override both of those instead of draw, or just put all your skinning code in draw and ignore the other two. Again, since it wasn’t designed with the idea of making this kind of thing easy in mind, you may run into various snags and problems. If there are some minor changes I can make to a component to make this kind of thing more easy, I’m willing to take a look at it.