Hi, just wanna share some ideas about how we can cleanup morph a bit. Layout.. bizarre. There are so many methods dedicated to laying out morphs that it easy to get lost. For me the main mystery and source of confusion is that there actually two different groups: - methods to control morph's own layout (in respect to its parent) - methods to control morph's children layout (something called layoutPolicy) the problem is that both APIs are found in single class, and most of them contain 'layout' word in it, so it is really hard to determine which one to use and when.. Over a years, i seen that people learned how to use existing functionality, without delving deep into implementation detail. But if you try to extend/change behavior (in your subclass), you will quite soon find out that it is really hard to tell with 100% certainty that the methods you override is the right place for your customization. Also, an important detail is extremely polluted protocol(s), making Morph a GOD class, with so many functions that it is unbearable. So, what i want to propose is same as i proposed to introduce for "SmalltalkImage" is to use "scoping" accessors , or "delegate" accessor to get access to part of functionality with clear context. Remember: Smalltalk vm version Smalltalk tools browser so, lets see how code might look like if we apply same approach to morph protocols: Example. Original: column := AlignmentMorph newColumn vResizing: #shrinkWrap; hResizing: #shrinkWrap; layoutInset: 1; borderColor: Color black; borderWidth: 0; wrapCentering: #center; cellPositioning: #center; color: Color white; yourself. Change: column := AlignmentMorph newColumn. column color: Color white. column layout shrinkWrap. "v and h both" column border width: 0; color: Color black. column childLayout inset: 1; wrapCentering: #center; cellPositioning: #center. Cons: - a code is a bit more elaborate. That because, of course, we cannot merge everything into single cascade. Pros: - from code it is clear, which properties belong to which parts of functionality. You cannot confuse, for instance, whether 'wrapCentering' property controls morph's own layout or a layout of its children - most important, we can considerably shrink Morph's protocol by removing all direct accessors and instead put them into delegated behaviors. More than that, a delegates don't need to be a dummy state holders (like most of properties are now), but actually an object(s) which conform to certain protocol.. For instance, if we have a 'border' as a delegate, and morph wants to draw it, it could just tell: MyMorph>>drawOn: aCanvas self border drawOn: aCanvas btw, then it is actually makes sense having a BorderedMorph subclass, which a) introduces 'border' delegate b) cares to draw its border in contrast to Morph who shouldn't. As well as in case of layouts, you can tell: morph layout changed. or morph childLayout layOutChildren. etc. -- Best regards, Igor Stasenko.