Stefan Matthias Aust sma@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