At 20:42 20.06.00 +0200, Stephane Ducasse wrote:

I decided to rejump into the morphic

Brave man ;-)

(without the refactoring browser nearly a nightmare ;)

Well, the current state is not the fault of the tools but of the tool users... even with an refactoring browser you can still forget to refactor or even have the delusion that there'll be time in the future to do a redesign.

So I would like to know what are the most important classes that I should study and relationships.

For a minimal morphic system, you need

o Morph o HandMorph o PasteUpMorph (former WorldMorph)

Morph is the base class of everything that can be displayed in a world and which what you can interact via a hand. If we look at the instance variables, Morphs have bounds and can contain other morphs as submorphs. The morph's own bounds merged with the submorphs' bounds is called fullBounds. As each morph can be a submorph of another morph, it has an owner. Every morph is directly or indirected owned by the world. The only exceptions are morphs picked up by the hand. Their owner is a hand which is not part of the world. Finally, each morph has a color (actually not the best idea) and other attributes which are modelled by the MorphExtension helper class.

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.

Each hand is an event source and you can register yourself for receiving events like mouse down or mouse moved. Normally, the hand automatically interacts with morphs so you don't need to register event handlers. Each hand also knows a keyboard focus, a morph that receives keyStroke events.

Each hand - normally represented by the hardware cursor - can switch to any form it wants and can bear user initials which helps to distinguish different mouse cursors. Actually all images but the primary hand are simulated. There're more instance variables to cache form images and to record damage done by morphs which what to redisplay theirselves while picked up.

Then a hand can send all events via a socket connection to some other remote hand. This code which burdens the already not trivial implementation, should be better factored out.

Finally, a hand controls tool tips (aka bubble help), popup menus and drag and drop. The hand also synthesizes the events it gets from polling during a world display loop.

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. It uses a few helper classes like WorldState or MorphWorldView and the things gets further complicated by the fact that you can have worlds in worlds and starting with 2.9a multiple active worlds. (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.

Here we see, that a world knows its hands, bounds and a so called step list which is used to animate morphs which registered theirself at the world. Actually each morph is steppable, that is, in periodic time steps, the world automatically calls a #step method which most often leads to drawing that morph.

The world is responsible to displaying it. Morphs ever directy draw theirselves but simply post request for redisplay which are collected by the world, optimized and then performed by calling the morphs' drawOn: methods. The world knows how often this should happen at most. Between each redisplay, all events of all hands are processed.

Actually, these three classes are enough to understand morphic and if they would restrict theirselves on the described functionality, morphic might be quite easy to understand and program. Unfortunately, all code is bloaded with support for scripting and probably also contains quite a few obsolete methods that got lost.

Morphs are the building blocks of morphic but if you want to create UIs, you need to know a few other morphs, too. A SystemWindow implements a toplevel window that can contain other morhs, typically Pluggable<whatever>Morphs. To implement menus, you don't need morphic but you can use the PopupMenu class and its friends. You might want to use an AlignmentMorph to layout other morphs but IMHO that is a faulty design and I'd either stick with the automatic layouting support of SystemWindows or construct a real layout morph with plugable layout algorithms, similar to what Java has.

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

Unfortunately, yes.

Was it the same in Self?

AFAIK, no.

    - Has any morph a player?

No. AFAIK, you don't need them if you don't want to use scripting.

    I was wondering if Morph could not be
    split into two classes:
    one without extension and etoy related stuff
    and one with extension.

Probably because everyone at Disney was busily working on their internal projects using the Ur-Morphic like a quarry for code, hacking any change in the system, delaying refactorings. A good design was not goal.

    A bit like what people made in VisualWorks were they split the
    View class into three classes (one with the controller, model).

Actually, separating controller and view isn't that useful, but separating the model is. There are MorphicModels but IMHO they're not obvious to use, and different to what one could expect coming from VisualWorks. It's nothing separated from the View (the morph) but a subclass. Pluggable*Morph thingys have no real models - compared with VisualWorks what I'd call a model. There's no automatic update of the view if you change the model. And without that feature, I don't need that models at all. A MorphicModel again is for scripting support as it can for example automatically generate and compile glue code. Pluggable*Morphs are such models but I think they don't use these features at all.

    - What is the difference with a player and an actor state?

Don't know

    - Is PasteUpMorph is the class of the current screen when I open
    a morphic project?

Yes.

    if yes (I hope that I understood right)
    why PasteUpMorph needs to have information about
    lastTurtlePositions, TurtlePen, TurtleTrails........

eToy

    I was thinking that only when we use morphic having player we would
    need that kind of information.

Sure.

    - FormCanvas has a strange classVariable called AA that nobody uses.

It's probably some artifact left over in you image. The current 2.9a doesn't have that variable.

bye -- Stefan Matthias Aust \ Truth Until Paradox