Morphic thoughts and Questions

Henrik Gedenryd Henrik.Gedenryd at lucs.lu.se
Mon Jun 26 08:57:00 UTC 2000


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






More information about the Squeak-dev mailing list