Today we address the changes that have affected some of the hierarchy shape and what happened to our old friend: ActionDisplay

Renaming and Refactoring

First off, an old class VisiblityAgent has been inserted as a superclass to all Agents that do visibility and enablement. Prior to this, all Agents had to handle visibility and enablement with, well, duplicated code. So, along with this refactoring, all of the duplicated code and instance variables that were repeated in all of the Agents that dealt with visibility and enablement are now encapsulated in VisiblityAgent. A lot of code was removed.

Along the way, someone noted that in displayOn: it was the burden of the developer to always check if the pane was open, if the clipping region of the graphics context intersected the area of the pane, and if the pane was visible, at the top of the displayOn: method. The point was, and I agree, it was wrong to demand that the developer have to copy this code for their own displayOn:. So now, an Artist's displayOn: method isn't even called if the pane isn't opened, visible and the graphics context's clipping area doesn't intersect with the pane.

Sorry Rita

Way back when, my colleague Rita and I, were hashing around the notion of CheckBoxes and RadioButtons, and how they might fit into Pollock's design. We came up with the idea of the ActionDisplay. The idea was, that a CheckBox and a RadioButton had an action part (the part where you click) and an optional display part (the label). Thus was born the name ActionDisplay.

However, in the intervening years, using that same design for the DropDownList, MenuButton and SpinButton, pretty much broke that notion. The name no longer applied. The notion of "action" seemed to apply to both the input field and button part of a DropDownList... certainly not the notion of display. And so on.

Vassili Bykov came up with a better name, ComponentPair, based on the notion that all of these panes represented a pair of panes, managed by one. The sad part is that even this isn't quite right! You see, CheckBoxes and RadioButtons, and the SpinButton on MacOSX, don't actually have a real pane as one of their parts. The check and radio is usually a crafted on the fly image. And in MacOSX, the spin parts of the spin button are also crafted on the fly images. The Agents and Artists conspire to fake you into thinking the are panes, but they aren't. So, it is possible that the name may change again.

So, ActionDisplay is now named ComponentPair. Where it used to subclass from ComponentPane, it now subclasses from AbstractPane. Similarly, ActionDisplayAgent and ActionDisplayArtist have been renamed to ComponentPairAgent and ComponentPairArtist respectively. Of course, ComponentPairAgent subclasses from VisiblityAgent

The "actionPart" is now named "headPart". The "displayPart" is now named "tailPart". All methods and instance variables have been renamed appropriately.

The "displayPart" (now named tailPart) has been moved from the Pane to the Artist, along side the headPart. This has become another bone of contention. There are many who look at the ComponentPane, and see that it's hosted panes are in the Pane, not the Artist, and then look at this new ComponentPair and say "They headPart and tailPart should be in the Pane."

In fact, from a purity of design point of view, I have to agree. However, the reason that the headPart (nee actionPart) was in the Artist in the first place was because it was sometimes a fake-out part managed and displayed by the Artist. Moving the tailPart (nee displayPart) to the Artist was done for the sake of simplicity of code. During the changes that occurred when refactoring the ActionDisplay into the ComponentPair, having the two "parts" co-located made for a significant reduction and simplification of the code, particularly in the Auto Look Change part of Pollock.

Simply put, because of all of the on the fly Artist behavior, moving the headPart to the Pane alongside where the tailPart (displayPart) used to live, simply wasn't a viable option. Thus, simplicity won out over purity. And this is why ComponentPair may yet be re-renamed. It implies a structure and behavior that is too similar to ComponentPane.

Overall, the new notion is that for a ComponentPair, the tailPart is sometimes optional. The CheckBox and RadioButton have optional tailParts (the Labels). This is unlike the other ComponentPair siblings; MenuButton, DropDownList and SpinButton where the tailPart isn't optional. Thus the "sometimes optional." Anyway, the common #addComponent: API for CheckBoxes and RadioButtons for adding the optional Labels (tailParts). This too leads to a confusion of the name, since this is a ComponentPart idea. <sigh>

More To Come

Next week I'll be skipping my Wednesday update... I'll be in a week long VisualWorks Engineering gathering. It is there were the final fate of the name of ComponentPair will probably be decided. The VisualWorks Engineering team is a far flung enterprise, where almost 2/3 of us work from home, from Canada to San Diego, from New England to California, and some of us scattered in between. Getting together like this allows us to work together on the many sub-projects of VisualWorks, working out the synergies and common designs for the next year.