Possible areas for Morphic enhancement
Last updated at 12:42 am UTC on 17 January 2006
2/13/2003
Diego Gomez Deck has organized a team to do cleanup work on Morphic – check out the "Morphic Cleanup Project (MCP)".
2/10/2003
From time to time there is a discussion about the pros and cons of Morphic. Ned Konz sent the following topic list to the email list which may serve as a guide for separating issues and organizing the further development.
Mon, 10 Feb 2003
- Morphic itself: composition, liveness, event handling, stepping, uniformity of interface, properties
- Standard user and programmer interactions with Morphs (halos, hand, etc.)
- Things built with Morphic: widgets, other Morphs
- Using Morphic to build "standard" UIs (consistent widget sets, UI builders)
- Support code for eToys and other environments like Wonderland and Croquet (players, vocabularies, etc.)
- The programmer experience (how easy is it to build things)
- The learning curve (how easy is it to figure out how to build things)(my preference is for steep (that is, quickly learned given enough focus) learning curves)
- Morphic's documentation and tutorials
All of these are to be found in what we've been broadly discussing as Morphic. I'd argue that these are separate problems which should be discussed dealt with separately.
Some of the problems I've heard discussed here relate to widgets and their use. These problems are at a different (and more trivial) level than Morphic itself.
That is: if Morphic (the infrastructure) itself is adequate, then it's a SMOP to rewrite or replace the existing widgets.
Other complaints are primarily code esthetics: Morph has lots of methods; there's impenetrable code in HandMorph and event handling, etc.
Still others relate to the ease of learning. As Andreas notes (Making Squeak more like Etoys), part of this problem is due to the use of inheritance for behavioral reuse (which forces lots of methods into Morph). And our standard tools don't really reduce the evident level of complexity far enough to prevent the all too frequent effect of new learners being overwhelmed by the sheer size of the interface. New tools like Traits and scoped browsers may help somewhat by scoping the available vocabulary.
Some complaints have been about performance (speed of constructing complex morphs like browsers and menus, damage calculation and extra redrawing, event handling, etc.).
Some other complaints (like part of the quoted one) have to do with the appearance or behavior of "standard" widgets. Many people believe that Squeak should provide widgets that are at least as competent and attractive as the Windows ones (some also feel that these widgets should look like the Windows ones).
Rather than saying "Morphic needs a rewrite" (which isn't likely to spur anyone into action), if you feel there's a problem somewhere in a specific area, then please describe the problem in its proper scope and offer suggestions (better, volunteer to lead an effort to come up with concrete solutions).
See also: Possible areas for Morphic enhancement
