Re-doing Morphic - damage calculation logic

Joshua 'Schwa' Gargus schwa at
Mon Feb 10 15:12:28 UTC 2003

On Mon, Feb 10, 2003 at 02:23:55PM +0100, Hannes Hirzel wrote:
> Hi all

> A partial answer to Andreas' ramblings that we are all kiddies who
> don't understand some simple 1500 methods while kids are using the
> result with ease.

I didn't understand his post this way.  I heard him say the 1500
methods aren't simple, and that although the kids don't understand
everything that goes on under the hood, they work within an
environment that is powerful, yet keeps them from messing things up.
He proposes working towards an ideal where Morphic and other Squeak
subsystems can be manipulated through an EToy-like interface (where
the important aspect is the limited vocabularies, not the graphical

> Of course having a heading like 're-doing' sounds a bit extreme but -
> Andreas - don't take that too 
> seriously. The Squeak community will be happy if this discussion leeds
> to some additional 
> enhancements.

I think that you're missing Andreas's point (or maybe I am).  I
understood him to mean that any code-cleanups and enhancements will at
best temporarily improve Morphic before the cruft comes back, since
you will be unable to force others to play by the rules of the

An example is not coding your new morph to report smaller damage areas
if it doesn't need to refresh the whole rectangle.  I had written
quite a few morphs before I realized that could be done, and how to do
it.  Documentation can help with this, but not fix it entirely.  How
can we ensure that only code that follows the "proper" framework usage
makes it into the image, even assuming excellent documentation about
the hows and whys of the framework?  The harvesters, already very busy,
would have to do much more than ensure that an enhancement didn't break
things.  I don't think that this is feasible.

As a bit of an aside, I believe that we need to reify some of the UI
behavior.  This actually fits in with Andreas's remarks about EToys
(the seed of the idea probably came from him).  For example, if the
event handling logic was expressed as a state machine instead of
regular code (where the states are in instance variables), then it
would be easier to create an EToy-like system to modify the UI
behavior, while enforcing proper usage of the framework.

> Actually Daniel Jones mentioned specific areas which need fixing from
> his point
> of view.  For his first point I include a test case below.
> 1) Fixing/improving the damage calculation logic.

How would you do this?  You can fix individual cases, but fixing
everything in a way that will stay fixed seems difficult.  Right now,
many morphs call #changed to notify the system that they need to be
redrawn.  This is straightforward for the programmer, but often
manifests itself as sub-optimal damage reporting.  For example, in
your SelectionMorph example, when the size of the selection is
changed, the contents of the selection are recalculated, and #changed
is called by #setSelectedItems:.  Ideally, you would only redraw the
morphs that entered/exited the selection, and the old and current
selection boundary.  The problem is that #changed is called from other
places that really do require a full redraw.  What solution can be
offered that provides the simplicity of calling #changed whenever you
change, without drawing more than necessary?  I have no answer.

> 2) Sane defaults for clipping/extents behaviour... ( Shrink some morphs,
> and watch the bizzare behaviour )

That sounds fine.  Before writing any code, please articulate what the
default behavior should be.

> 3) Fixing Halo/Handmorph
> 4) Combining all the variant widget morphs into one consistent set.
> There 
> are several versions of common basic widgets, all specialized cases 
> that could be handled by a well designed and general widget. Plus, 
> radio button, checkboxes, and other basic widgets are missing. The base 
> squeak image needs a full set of working widgets.

This would be very nice.

<damage example snipped>

> I think that Morphic is a great achievment; it has great new ideas and
> for a research project it has a good implementation. But there is room
> for improvement.

Yes, but cleaning up code here and there is not a long-term solution.


> As a contrast: I took the above 625 colored squares and generated an
> html files with 625 divison tag pairs (with a colored background and
> pixel-positioned absolutely with CSS) and looked at them with IE5.5
> Windows and Mozilla 1.0): IE5.5 didn't show all the squares while
> Mozilla did. 
> Hannes Hirzel

More information about the Squeak-dev mailing list