Over the years, I've watched much be said about the classical VisualWorks widget framework. At some point, it picked up the name "Wrapper"; I've come to distrust this label as it tends to often accompany a categorical dismissal of the whole thing.

I do not generally share in the holistic judgement of badness that is attributed to "The Framework Known as Wrapper." It's not that I'm in love with it either. It's got some ugly code in it. Code written by junior Smalltalkers who passed through the halls of ParcPlace and its other names, code that was never cleaned up. There is, in my mind though, a difference between a poorly written menu bar widget, and a fundamental flaw in the model the library presents. A poor widget can be fixed, improved, replaced. Fundamental kingpins of the library's model are harder to overcome. Of course, there's a lot of gray in between these two idealistic spectrum points.

I've reflected over time on what fundamental flaws it does have, and tried to distill what they were, for me. I'll share what I think the two biggest mistakes were.

LayoutWrappers

This is probably where the library earned it's current slang name. At the heart of Ye Old ObjectWorks widget model, is a class called VisualPart. All (or at least most, there's probably some experimental esoteric thing out there) widget kit library things boil down to a tree model of widgets, contained in a child/parent relationship, each usually contained within the parent's rectangle by an ever smaller rectangle. When you have this tree structure, you can basically go two routes when it comes to modeling the sub/super relationship between these widgets. You can have different object types to represent the different node types in the tree (i.e. nodes with children vs leaf nodes), or you can just mash them together like Morphic/Cocoa do and have one kind of node with 0 or more sub parts. There are trade offs either way. I have my preferences, but I don't think that doing one or the other makes or breaks the framework. In the VisualPart heirarchy, we find CompositePart playing the role of the "node containing children" and other classes (usually View) playing the part of the "leaf node". And then, there was a special relationship that was apparently common enough to warrant yet a third node type: Wrapper. A Wrapper is just a VisualPart that has exactly one child. So far, I'm OK with all this. I wouldn't do it this way necessarily, but the great sin hasn't been committed yet.

At some point, someone got excited about the compositional nature of a Wrapper, and decided that visual parts themselves would be clueless about their position on the screen. Not only would they delegate this to another object, but it must have seemed like a cool proof of concept, to use a Wrapper to do it. Where a widget is positioned, is not a property that should have been "wrapped around" a widget. It's apparently so fundamental that every visual part needs one. That should have told us right there, that it belonged as a basic attribute of a visual part. Not wrapped around it. This lead to a pattern of creating a doubly linked list of objects to compose a widget. In time other attributes, less heinous, but still questionable, were also balled up in wrapers. What programmers saw on the screen as a single thing, was actually a doubly linked list of arbitrary objects. Does this mean all wrappers are/were evil? Not at all. A part that contains another part and adds something around it, something that is not intrinsically necessary to the widget, is not a bad idea. It's cool that if I wanted, I can stack 17 bordered wrappers around an object (I'm not saying this is the way it should be done, but it's cool, and it's not a make-or-break issue). This was error #1. It predated the actual introduction of the VisualWorks product name.

UIBuilder

In the mid/early 90's, I built lots of GUI's with ObjectWorks. They were complex engineering automation tools, involving visualization and interaction that was both normal, and sometimes not so. I ran circles around fellows using other toolsets. In those days, there was no UIPainter, and no UIBuilder. Somewhere in there, it got popular to play in the 4GL space with click-and-snap "wysiwyg" window painters. Visual programming was at its high. And the guys at ParcPlace rushed to compete. This was not a bad thing. At first, I thought the new tools that the newly named VisualWorks provided were pretty cool. For oft repeated tool design, it was kind of nice. But it broke down quickly.

For me, I knew how the VisualPart framework worked. I'd been using it for a while. So I could see how this stuff simply put together stuff I'd been doing for a while. But as I watched new people come to Smalltalk, I saw their bewilderment at understanding the stuff. The problem was that to them, the first view they had was how to drive the UIBuilder. A single object with way to much behavior, huge methods, and the inputs to it weren't really objects. They were these hard to read spec arrays. Spec arrays versus the elegance/expressiveness of actually Smalltalk code. Hmmm. Programming UI's in Smalltalk was supposed to be about programming Smalltalk. What people ended up programming was Spec-ese through a compiler known as the builder. And that's not an engine that had anywhere near the legacy of development and exploration as the Smalltalk system itself. I'm often amused by the irony that wanting a UIPainter for Widgetry has presented. While painful to have to program Widgetry without such a tool, it is exactly this exposure to the objects themselves, that can make Widgetry seem more approachable than the old system. I'm not saying a UIPainter shouldn't exist; I'm saying that it should generate Smalltalk code. The distance between such a tool should never create a sense of "separation" between two ways of doing things. It should make mundane things easy, and allow you to step right to code when you need to go further. And you lose the opportunity for the tool to create an artifact that teaches you the APIs, rather than hides/obfuscates them.

To this day, I'll use the builder based tools only for a short time, before I discover "screw it, it won't do the dynamic thing I want to do." Then I just step around it and make/manage my own visual parts. But others haven't had that exposure, and we've done a terrible job of hiding that knowledge and not documenting that as the primary way to learn about the widget system. I don't believe you'll find a fundamental discussion of how the view tree works anywhere in our docs, and what objects play what roles.