Morphic Layout

karl karl.ramberg at comhem.se
Sun Feb 25 22:52:45 UTC 2007


Andrew P. Black skrev:
> 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
>
Since you are not using morphic layout don't use layoutChanged. I think 
using changed is the old morphic way of doing layout and will probably 
work better.

Karl




More information about the Squeak-dev mailing list