Over the years, I have written a lot of custom widgets with VisualWorks. At Siemens we built lots of almost cad like interactive tools for commerical nuclear fuel burnup simulations. And at Key, well, there it was all touch screens, and you had to present manipulating three dimensional color spaces in ways that make sense to operators whose career aspirations are not to high. So, I've done quite a few of my own custom widgets over the years. I've always been pretty comfortable with the MVC pattern as a solution for these. One thing I noticed though, was that I got tired of writing custom controllers. They were often just one or two methods. And they seemed to require lots of interaction with the view. And often mirrored the same algorithms (e.g. we draw a line based on the model in the view, then we determine where a mouse click is relative to the line in the controller). Which seems wrong from an encapsulation point of view.

At some point, I got tired of it, and wrote BetterWidgetController (and it's helper that you don't care about called BetterWidgetTracker). I would implement

defaultControllerClass
	^BetterWidgetController

in my View class and then implement

defaultController
	newController := super defaultController.
	"configure newController"
	^newController

The API for BetterWidgetController was all about blocks I could set up which would then interact with the View. I would often just have have the blocks call a method the view implemented. The three main APIs were:

• upBlock: - takes a one argument block. The argument is the point the mouse went up at.
• downBlock: - one argument block again. The point the mouse went down at.
• moveBlock: - one argument block; the point the mouse moved to.

The mouse points were always relative to the view. Which was nice because they were then consistent with the model the view had. Over the years, I converted probably 95% of the controllers I ever wrote to use this guy. I added "helper" APIs such as selectBlock: which handled the transaction of a "click" making sure the click started and ended in the view. Or the beTriggerOnUp implementation.

I used it once again in the Cairo Visualization stuff I blogged about recently. It allowed me to throw together the "drag the nodes around" interaction in about 2 minutes. If I was going for something more than a demo, I would probably have factured it down into sub methods. It looked someting like:

defaultController
	| newController anchor |
	newController := super defaultController.
	anchor := nil.
	newController downBlock: 
			[:pt | 
			(model findThingNearest: pt) ifNotNil: 
					[:thing | 
					anchor ifNotNil: [model anchors remove: anchor ifAbsent: []].
					anchor := model anchors add: (Anchor for: thing at: pt)]].
	newController upBlock: 
			[:pt | 
			anchor ifNotNil: 
					[model anchors remove: anchor ifAbsent: [].
					anchor := nil]].
	newController moveBlock: [:pt | anchor ifNotNil: [anchor position: pt + 0.5]].
	^newController

One of the nice things about it from a prototyping view, is how you can create shared context between the three blocks, because of real closures.