This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: LordOfTheLayouts
Feed Title: Travis Griggs - Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/travis-rss.xml
Feed Description: This TAG Line is Extra
One Layout to rule them all
One Layout to try them
One Layout consume's them all
and in composition bind them.
Layouts, especially when you're prototyping some interesting widgets and interaction between them, get to be your friend. VW has two basic workhorse Layouts. One is the AlignmentOrigin. This is great for visuals that have a fixed rectangular size (e.g. labes), and you'd like to position them. The other is the LayoutFrame. This one for malleable rectangular widgets, allows you to specify the 4 edges as relative layouts followed by pixel offsets.
What though, if you want to specify a widgets rectangular size (it can't really give a good preferredBounds itself), and then position it like a label? You'll make an AlignmentBox problaby. What if you want to apply a pixel offset and then do the fractional thing? Maybe you'll do a BackwardsLayoutFrame, or maybe you'll generalize the idea and make a NestedLayout (which allows Layout objects to be stacked). Sooner or later though, you'll tire of all this nonsense.
There is one basic job of the Layout object. Returning a rectangle (top, left, right, and bottom) when queried with a) the containing rectangle and b) the preferred bounds of the widget in mind. Mathematically, we might like to say something like f(left) = ... When laying out widgets that is what we think. For example, "I want this widgets left side to be 100 pixels from the edge. Turns into something like f(left) = 100. You could use a simple Layout object for this. But what if you want something that says "The left of the widget should be 1/Nth of the containing rectangle, but after subtracting half of the containing rectangles height off of both ends, so we can draw unobstructed semi circles on the ends of the containing rectangle". It's a bit harder to concoct that with the existing static jobs. But in "function" speak, it boils down to something like:
left := outerBox width - outerBox height / N + outerBox width half
Needing to do just that and tired of not quite having the right Layout once again, I sat down and made LordOfTheLayouts. It has four accesible ivars (and one private one). Alan Knight once told me that "any object which uses 3 blocks in ivars to parameterize its behavior has issues". LordOfTheLayouts has four. Basically, it uses a "valuable" object in each of its left, top, right, and bottom slots. IOW, it represents the layout alrogith as of f(left), f(top), etc. Having this guy is just terribly liberating. Suddenly, I the programmer am not constrained to layout widgets with in the narrow religion defined by the existing framework. I can, with little effort, do any kind of layout I can dream up of, and that's what Smalltalk's supposed to be about.
A few thoughts on "programming with lots of blocks".
1) They're harder to debug. Yup, you can't open a debugger and make a change and have it "take". But you actually can if you use the block as a "hook", but put your code in your own instance specific methods.
Now you can "tune" the behavior on the fly without having to "rebuild" the thing.
2) To me, making oft tuned objects use blocks to parameterize their behavior makes the system more Self-like? One of the main push's in Self was to get away from the "class" constraint, and be able to do more flexible instance based specialization.
3) Having this much flexibility is dangerous because I can make a spaghetti meatball algorithm which might go recursively infinite and be a real pain to figure out. For this reason, LordOfTheLayouts keeps track of block execution and will trap/error on a recursive condition.
4) The cool thing about LordOfTheLayouts, is that you could actually add the instance creation methods from the other Layout classes to LordOfTheLayouts, and then get rid of all the other Layout classes. It is a complete superset of all existing Layout objects. I'm not doing it justice, but I'm reminded of Vassili Bykov's excellent post where he posited (for amusements sake) replacing all classes with blocks.
Previous Topic
