Morphic Layout

> In my continuing quest to make sense out of Morphic, I've been
> wrestling with the following problem; I hope that someone can help me
> to a better solution.
>
> I have a Morph, which contains some subMorphs.  For the sake of
> concreteness, the Morph is a view on a die (just a square with rounded
> corners), and the subMorphs are the spots that represent the six, or
> the four, or whatever.  I have code that changes the view when the die
> is thrown; this code works by removing the current set of spots and
> adding the new ones.  The spots are laid out manually, not using
> layout policies or anything fancy; the size and position of the spots
> is computed from the current bounds.
>
> When the outer morph, the DieView, is resized, I obviously need to
> re-do the layout of the spots.  So I wrote something like:
>
> DieView>>layoutChanged
> super layoutChanged.
> self changeSpotsTo: model value.
>
> which takes advantage of the existing code to set up the spots again.
>
> The problem is that the changeSpotsTo: method does its work by
> deleting the current set of spots and adding a new set.  The removal
> and addition of submorphs causes layoutChanged to be sent to the
> enclosing Morph, the DieView, which causes an infinite call cycle.
>
> The following code works:
>
> layoutChanged
> super layoutChanged.
> alreadyComputingLayout
> ifTrue: [^ self].
> alreadyComputingLayout := true.
> self changeSpotsTo: model value.
> alreadyComputingLayout := false
> but I'm ashamed to show this to my class :-(.
>
> What is the "right" way to solve this problem?
>
> Another way of asking this question might be: layoutChanged is used
> to propagate changes in layout UP the Morphic containment hierarchy.  
> How should changes be propagated DOWN the hierarchy?
>
> Andrew
>