Hi Todd,

> > Also, Morphs should actually be rather robust in this area - 
> > #fullBounds contains an error handler which will fix up its
> > bounds if a problem is encountered in the layout process before
> > passing the error.
> 
> Yeah, but this doesn't do anything for detecting infinite recursion - 
> which is really quite easy to induce I think.

I don't think so unless you were breaking the morph hierarchy. But it's a
good point nonetheless - I think that you _should_ be able to break out of
those infinite recursions with Alt-Period but as of now this won't work. Hm
... thinking about this ... what happens if you assign fullBounds initially
_before_ the layout computation?! Would this work?! It would at least ensure
that if you're interrupting there's some valid value in that field which
should prevent further errors.

> Well, I was trying to write a new layout manager - but looking at the 
> two existing ones didn't really give me a clue as to exactly 
> what I was supposed to do with my new bounds that I calculated.

Why, assign them, of course ;-)

> The various bounds aren't too easy to figure out either.  fullBounds, 
> outerBounds, layoutBounds, innerBounds, bounds.  Holy cow. 

That's unfortunately true, but they are really needed.

> I figured out that layoutInset doesn't seem to be used anywhere but 
> TileMorph and nuked it.

You _sure_ about that? I'd say that there's a good chance that the
layoutInset is used in more places.

> For the added complexity, I think we could do something 
> special with TileMorph if you want a 1 pixel horizontal margin.  Like 
> use the struts and springs layout and initialize it with a 1 pixel 
> strut on either side and a springy middle.

Whatever gets the job done ;-)

> In reference to Stef's message - if you were to do Morphic all over 
> again - what would you change?

In what area?! Graphics-wise, morphs should have local coordinates as well
as a full transform. Composition-wise, a morph should be made up of a set of
individual, atomic aspects which describe the basic visual properties (fill,
border, text, graphic, etc) and do essentially "just" the integration of
those. Layout-wise, we need something that abstracts a little from those
"wrapper hierarchies" which really get into the way - after all what you
_really_ want to see is the "meat", e.g., the guys actually doing anything.
In addition, I think we need a less global control about the layout aspects
- what's in there right now works perfectly well "if you know what you are
doing" but that's exactly the problem. To many combinations lead to
unforeseeable results.

Cheers,
  - Andreas