Stefan,
great comments.
HandMorph is the class representing a mouse cursor. Morphic supports more than one hand, even hands controlled by other systems, called remote hands, or controlled by an event recoder, a HandMorphForReplay thingy. Normally, there's one primaryHand per world and one activeHand during event processing. There's also the notation of a currentHand but I think, either primary or current but not both makes sense. A hand morph has some 30 instance variables - most of them results of poor refactorings. They hold internal states like time between double clicks or the active popup menu.
I've been thinking a lot about the HandMorph, much because I've had to implement a different (I just barely managed not to write "better :) interaction style, which is _very_ difficult. Refactoring the hand is very difficult since there are loads of gratuitous dependencies in there, esp. wrt eToy. I've now come to think that this could be remedied by introducing an "InteractionStyle" class that the hand delegates event handling to. This is the only reasonable way I see for improving the situation while still not breaking scripting and a lot of other stuff. We'll see how far I get.
A PasteUpMorph is a container, called a world, that contains all other morphs and bridges that world and other morphic worlds or the old MVC system. ...
(Actually the hole class is a mess and as Stephane already noticed, it contains a lot of stuff which should better refactored to specialized classes). Looking at the instance variables, we see that a world can have a presenter and a model (I don't understand that) and much other stuff like a background or some not yet working (or agan broken) things like support for hypercard-like stacks. More important are the variables of the world state.
There is really little reason why the world would have to be a PasteUpMorph--the functionality you mention is all related to eToy stuff, none relevant for the world as such (as opposed to eg. the worldState et al.). This is a great 'refactoring opportunity'. In fact, it would be interesting to see if a plain generic Morph or similar could be used for the world.
I was wondering if Morph could not be split into two classes: one without extension and etoy related stuff and one with extension.
The MorphExtension is in fact meant to do just this, sort of--it is meant to hold stuff that needn't go into most morphs. Most of these things are _not_ related to scripting/eToy: eg. locking, being sticky, and so on.
Henrik