At STIC I gave a talk about Skins. Skins are a way of separating display behavior from widgets, and trying to rectify some of what we see as "no longer sound" design decisions. At one point, I had put this graphic up on the screenfollowed by this one
It describes the central, fatter role, we're trying to give widgets we develop with the Skin mindset in mind. The one thing this kind of Widget does not do, is actual drawing.
I was asked later on "so, if we wanted to do some new widgets in with this newer GUI approach, how would we do this? Would we make a new skin?
The answer is no. Or at least, most likely not. The whole point of separating the drawing behavior into stateless policy objects, is to deal with having a single widget object, that can be rendered in different look and feels. But for most custom widget development, you don't care about different looks. You're not trying to ape Windows or OSX or something else, the look of your widget tends to be uniform. And so you don't need the whole separation/decoupling that a skin approach provides. You just have your Widget do it's own #displayOn: method.