Re-doing Morphic ( Was: Re: Traits prototype image )

tblanchard at mac.com tblanchard at mac.com
Tue Feb 11 01:11:51 UTC 2003


On Monday, February 10, 2003, at 01:16  PM, Andreas Raab wrote:
> Simple. I think that all'y'all (thanks Jeff!) are barking up the wrong 
> tree.
>

Could be.  To be honest I've spent the last day or so digging into 
Morphic, reading the tutorials (there are actually quite a few) and 
digging into the code.  I've also wrecked a few images by making little 
changes and having the entire UI freeze up on me.  :-/  I can see 
modifications are going to be painful.

> To me, this is the logical result of many of the shortcomings of 
> Smalltalk.
> For example, subclassing for using the framework. When we subclass a
> framework class like Morph in Smalltalk we do not *use* that class but
> rather we *modifiy* it. We are able to access unprotected instance 
> state
> (look at the ridiculous comment in Morph>>bounds) we are able to 
> override
> system critical methods in incompatible ways. Even the tutorials (like 
> the
> one up at Squeak.org) teach you that it's okay to break the framework 
> in
> order to use it (in this concrete example, it lacks calls to any of the
> "super" methods even though this is required by the framework).

Hmm.  I agree with your assessment.  Subclassing is, in my mind, always 
the last resort.  I would point out that Cocoa gets around this problem 
using a pattern of delegation.  Now that I've dug into etoys and 
figured out how players work, I see that these are also delegates of a 
sort.  Sadly, delegation is an underused technique.  I think Morphic 
could benefit from added support for delegation regardless.

> Given this, any attempt to "clean up" Morphic is doomed to fail if it 
> does
> not address the "usability issues" for the programmer. The best you 
> can hope
> for is a temporary effect but any newbie can (and therefore will!) 
> write
> code that breaks the framework.

This is true, but newbies are less likely to make crappy new parts if 
they can find parts that already do what they want and they have a good 
way of using/customizing them without subclassing them - I assume this 
is what you are getting at?

> eToys do exactly this.

They provide cool user-configurable delegates with a nifty UI as far as 
I can see.  This is a property totally worth preserving and possibly 
expanding.

> Of
> course, such an environment would no longer be "Smalltalk"

I don't understand what you mean by this.  It doesn't require a 
language change to make this happen - just a conceptual shift for the 
developer I think.  I recall that when building UI's in visualworks we 
hardly ever subclassed anything.  We just stuck things together.  Same 
is true for Cocoa development.  OTOH, people have clearly built a lot 
of morphs - some not so good it seems.  But I think this is a symptom 
of not being able to find something that already does what they need.

> Bottom line of this: Morphic is cool.

Oh yeah.  The more I dig into it the cooler it gets.  But it (or I 
should maybe say things we use every day that were written with it) is 
kinda buggy.  You can see it in display update errors.  If nothing else 
happened but redraw was cleaned up I'd be pretty happy.

I'm glad you spoke up.  Your comments inspired me to learn a lot.

Todd Blachard



More information about the Squeak-dev mailing list