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
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
> 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
> (look at the ridiculous comment in Morph>>bounds) we are able to
> system critical methods in incompatible ways. Even the tutorials (like
> one up at Squeak.org) teach you that it's okay to break the framework
> 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
> 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!)
> 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
> 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.
More information about the Squeak-dev