I didn't write this originally, but - one of the things that makes Morph the hub of a big tangle, is the fact that it references classes it shouldn't know, for example, alot of it's own subclasses. In another example, Morph should probably not be dependent on FileList. These references should eventually be either moved into a more specialized subclass, moved to a class extension method category (see DVS), or the design changed such that the reference is replaced with a weaker form of coupling. These are medium to large refactorings we should get to eventually (dvf)

It looks like borders have been factored into BorderStyles. Unfortunately they are almost completely undocumented. This may place BorderedMorph into the same category as AlignmentMorph (obsolete but kept around for compatibility.(efc)

Morph>>delete the last #ifTrue:ifFalse: has the same code in the beginning of both blocks (dgd)

Morph>>allMorphsDo: has an unnecessary size check (dgd)

categorize methods isXXX as testing (dgd)

I'm not sure if this is a good idea (gm). There are 39 isXXX in 12 categories. Use the following lines to see them:

PluggableListMorph and SimpleHierarchicalListMorph common code should be in a superclass (existing or to be created). common code = scrolling, keystroking and more. It was nonexistent in second class, was added by SqueakMap package Hierarchy List Morph - Navigation

Change submorphs to use coordinates in terms of their parent morph. This will reduce the need to keep all the bounds rects of all child morphs updated on a drag or move. This will require updating drawing code too but maybe we can work around this by having the parent morph set up an offset before calling #drawOn:

The tradeoff here is when the translating work is done. Currently, translation work must be done for every move, but after that each drawing operation is "free". The proposed scheme would make moves "free" but require translation work on every drawing. Since almost every move requires a redraw, I think the current situation may be the best, but we can continue thinking about it. -efc

WRONG The drawing operation is not free at all. In fact, even today it uses about everything that you'd need with local coordinates. IOW, the current situation is the worst case in about every respect (-ar).

Well, the current situation doesn't require point translations on every redraw, does it? A local system would. Intelligent caching could prevent the entire translation chain from being redone, but still you have every single Morph doing translating on every redraw, compounded by the immutable Points and Rectangles that are usually created in great numbers during the translation.

Refactor #bounds:,position:,#extent:

please give us more details (dgd)

Currently, #bounds: results in separate calls to #position and #extent, which do some redundant work (multiple changes/damage reporting). Perhaps this need only be done once?(efc)

Clean up layout and redraw protocol - how many different kinds of bounds are there and how do they interact? Efforts to add a new kind of layout have had me breaking images (frozen UI) for a week now. This is too fragile.

Good idea. (efc) Even if there are no changes, we should provide (good) documentation on the various bounds and changed protocols. A thorough commenting on the entire class Morph won't hurt either. Some of the more common head-scratchers:

changed, #layoutChanged, #ownerChanged

bounds, #outerBounds, #fullBounds

Remove direct access of instance variables (proposed by dgd)

bounds ==> gm: just search references of bounds? The problem is in the hierarchy...

Class Comment documentation: I am starting comments for some underdocumented Morphic classes here: Class Comment Drafts (Morph menus). Would you like the finished changesets posted on this page somewhere? Possibly not in the MCP changesets.. they are not tightly coupled, and I don't see much reason to mix them.

WaveEditor #normalize: seems unused. (gm)

TransitionMorph #drawZoomFrameOn: and #drawZoomOn: are almost identical (gm)

KeyboardMorphForInput #emitRest and #mouseDownPitch:event:noteMorph: are almost identical (gm)

MidiInputMorph #atChannel:from:selectInstrument: and ScorePlayerMorph #atTrack:from:selectInstrument: are almost identical