A little while back, I posted about a HorizontalPanel object that I was using in the browser. It was meant to show that custom layouts using custom subclasses of CompositePart were not that hard.

I've gone a bit further now. The latest version of the RB has removed that class, and replaced it with just Panel. Panel's an ambituous experiment. It's inspired by some of the work Michael has done in other projects, and some of my own experience. I expect some of it to evolve still.

Panel is a subclass of CompositePart (for now), but it has some key differences:

1. It does not used Bounded/TranslatingWrapper for it's subParts. No wrappers at all. The real components are stored directly in the components instance varible (which is usually aliased as "subParts"). So this shows that steps can be made to removing wrappers from the system. I've identified some ugly parts of the system (particularly TranslatingSensor) which need to change to make this ideal more realiizable. I've also figured out one way of solving the problem of being able to add VisualComponents as leaf nodes in the view tree.
2. Unlike CompositePart which defers all layout of subParts to Layout objects which are attached 1:1 to the subParts and clueless of one another, it uses a layoutBlock to layout the children. I expect to tune this piece some. But I'm able to do the layouts I've wanted to so far with it. Since it's a block, it can be a very simple function, or a complex one that shares state between invocations. And before I get comments to the effect... just because a block is used, doesn't mean one can't put a real object there, and simply wrap it in a block.

I'm in the process of doing a minimal modification of RBSUnitExtensions so that it works as status bar, instead of a wrap-around-code-tool. I'm using that effort as a chance to follow "wouldn't it be nice if the framework supported this" tangents. Back to the grind.