Re-doing Morphic

Daniel Joyce daniel.a.joyce at
Sun Feb 9 16:46:54 UTC 2003

> I'm very well versed in Cocoa, Swing, even Motif.  They're all kind
> of the same thing and they all take a lot of additional coding to get
> to something useful.  I get the idea that Morphic was sort of
> reaching for the Hypercard on steroids kind of thing (which is good -
> HC was quite possibly the most productive tool for building quickie
> apps I've ever used - so far).
> So rather than set out to build YAWidgetKit, I'd like to try to see
> what's already there and maybe do a clean implementation of the
> original design with improvements.

I agree, but alot of Morphs are cluttered full of one-off class specific 
extensions if if-else logic. Ugly.

The widgets need to cleaned up, and bulletproofed with SANE defaults ( 
Like, clipping ON for almost all widgets). Plus cleaning up some other 
bugs ( Shrink circle/rectangle morphs small enough, and they act weird, 
the sides pass through each other ).

Also, fixing/improving the damage logic.

I think the two biggest things are...

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

Improved damage calculation logic.

Then we can look at

Fixing Halo/Handmorph
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.

Investigate the options for integrating 2D improvements with 
3D/Croquet/etc. Are there useful imaging/rendering models out there? 
What has been done before? Is a SCG rendering model really an option?

About breaking things...

Sometimes, you just have to do it.

Linux would never advance if from time to time driver modules, or other 
features weren't 'broken'.

If we find a feature that needs to be redone, we should break it, but 
give notice. Traits would be very useful, as we could factor the old 
behaviour into a 'deprecated' trait, and after 6 months, or next major 
release, 'break' it. 


More information about the Squeak-dev mailing list