Stefan Matthias Aust <sma at 3plus4.de> wrote:
> 
> The new UI framework should be small, fast, easy to understand, simple to
> extend and still powerful.


Morphic is actually pretty straightforward.  Morphs have submorphs. 
Morphs respond to events.  Morphs have a color.  Morphs have a
rectangular bounds.  The top-level morph is called a world.  Etc.  This
stuff is very easy to understand, except of course that it isn't
documented anywhere.  :)

As for small frameworks, Morphic isn't, but the one you describe doesn't
seem exactly "small", either.  Graphic frameworks seem to have a
fundamental complexity about them.


As for speed....  The *big* slowdowns I've seen, though, are *not*
because of the framework, but because of particular widgit
implementations:

	1. Large PluggableListMorph's are slow because they format all of the
constituent StringMorph's whenever the underlying list changes, instead
of just drawing the items that are actually visible.

	2. Large TextMorphs are slow becaus the text implementation is slow for
large chunks of text.

	3. Moving windows is slow because of the drop shadows, and because
movement is usually solid-filled.

That said, no one has really figured out exactly why Morphic has a
slower feel.  Perhaps it is simply that the above widgits are slow?  Or
perhaps it is something fundamental.  What we really need are
*profiles*, not more guesses.  A good start at this would be for people
to simply *list* some operations in Morphic that are slower than the
correspondents in MVC.  People who have slowish computers should be
especially well equipped to do this :)


Anyway, can we stop taking these huge broadsides against Morphic, and
start talking about individual issues?  It would be much more
productive.  For example, Stefan proposes that not all Morphs should be
able to have sub-morphs.  Is this a good idea?  bad?  I don't know, but
it's an interesting idea worth talking about by itself.


Lex