Stephane Ducasse wrote:

> 
> Hi all
> 
> I decided to rejump into the morphic (without the refactoring browser nearly a
> nightmare ;) Everybody should look at that if we want to have a chance to
> have good good. (if doing a change cost 5 min and you have 10 s
> may be in 2s you will do it!))
> 
> So I would like to know what are the most important classes that I
> should study and relationships.
> 

Try eg. RectangleMorph as a reasonably representative, plain vanilla morph,
and the 'core' categories of Morph and HandMorph for core functionality. I
proposed a couple of months ago that the core of Morphic be purified,
especially by separating out all the eToy stuff that is spread all over the
place.

> For the moment I have:
> Morph (horrible Blob class)

well then you haven't looked closely at HandMorph ;)

> MorphExtension
> Player??
> PasteUpMorph
> HandMorph


> Up until now my view is extremely blurry.  I understand how to use
> pluggableMorph to create widget.

Unfortunately, pluggableMorphs are not very representative, but rather serve
for backward compatibility. In general, widgets are not good examples of how
Morphic is meant to be used--in fact much the opposite. They have been
brought into it as the Smalltalk legacy.

> I understand that a morph may have an
> extension that provide extra state.  I understand that a world has a
> worldstate that holds a canvas on which every morph will draws itself.
> 
> I try to understand Morphic by looking at class catgerories per categories.

Good strategy. Unortunately it doesn't work very well here :)

> In fact I really have the impression that Morphic are impacted by the
> scripting, turtle etoy like stuff.

You got that part right :)

> Was it the same in Self?
> I was dreaming that in Self the model was simpler.

I think it was better there--because there was no eToy stuff--all the
experimentation that has been done with eToy seems to have left its traces
in more than one place.

The dream I have been having is that the eToy stuff would be separated from
Morphic to the point of being removable from the image/in a separate
namespace. But I don't see it at all in my crystal ball...

> 
> I have a bunch of questions
> 
> 
> - Has any morph a player?
> For example, I have the impression that the pluggableMorph
> do not have one. 
> When the player is necessary it is hold in the morph extension.

I'd say, forget about players, unless you're in eToy. They're completely
eToy-related. I still don't really know what they do :) In fact, my best
hint for learning Morphic is to completely disregard the eToy stuff. Now if
that was just a little bit easy, since it is so completely intermingled with
everything else in all the wrong places...

> I have the impression that the player is only needed for the
> scripting environment. So or a basic player should be put in
> the Morphic Kernel or I was wondering if Morph could not be
> split into two classes:
> one without extension and etoy related stuff
> and one with extension.

The extension is really a general mechanism used to save memory, by putting
rarely used items there. I think this could be done a lot more cleanly in
Self by adding slots to any single object.

> A bit like what people made in VisualWorks were they split the
> View class into three classes (one with the controller, model).
> 
> - What is the difference with a player and an actor state?
> I really the impression that actorState has nothing to do with
> Morph but is just an impact of scripting eToy,

eToy, eToy, neither are relevant to Morphic in general.

> - Is PasteUpMorph is the class of the current screen when I open
> a morphic project?
> if yes (I hope that I understood right)
> why PasteUpMorph needs to have information about
> lastTurtlePositions, TurtlePen, TurtleTrails........

Yes, and that's a good question, and that's a good example of what I mean by
eToy showing up in all the weirdest places, which is why I think the chance
of it being factored out is slim...

 As I see it now, no one outside SqC can really even try to do much cleaning
up in the core, since it would surely ruin eToy, which would probably reduce
its appeal to SqC as an 'improvement' to Squeak. After all, to a major
extent, eToy is what SqC is using Squeak for...

Henrik