Peter Crowther <Peter.Crowther at IT-IQ.com> wrote:
> I've stuck with MVC partially for (now-solved) performance reasons,
> but principally because MVC is small and simple enough that its behaviour
> can be understood by studying the methods and method comments.  The times
> I've tried to learn Morphic, I've got baffled early and have had no way of
> finding out why the behaviour is as it is.  I wish I could volunteer to act
> as co-ordinator for documentation effort, but I'm already up to -here-
> (indicates point well above head height) in other docs.


This is wierd for me to read comments like this, because I tried 2-3
times to learn MVC but gave up due to all the transformations.  Morphic
has made sense from the beginning; it's always been a matter of "surely
there is a method for this, now what's it called?".  I haven't had any
deep aha experiences with Morphic, because it was so similar to window
systems I already knew about.  Instead, it's been a steady accumulation
of almost-trivia about what the specific names of the different parts
are.

In a nutshell, a Morph knows how to draw itself.  It knows its bounds. 
It can have submorphs.  You can add and remove submorphs.  And so on.

Going up a level, HandMorph does all the drag and drop and halos stuff. 
It asks that morphs can choose which submorph will respond to a click. 
It will send the actual click event to a morph.  Same with the keyboard.
 It does halos.

Up yet another level is the media and scripting environment being
developped, but I don't think most people mean this when they complain
that Morphic is hard to learn.


Anyway, to make a nutshell of the nutshell, reading through Morph and
HandMorph is a pretty good way to learn how Morphic works....  Then it's
just a question of getting familiar with the particular widgets
available already.


Lex