Re-doing Morphic ( Was: Re: Traits prototype image )
sps2000 at mail.com
Tue Feb 11 02:20:02 UTC 2003
Andreas Raab wrote:
[snip have been applied]
> The problem is not "cruft in Morphic", it isn't "uglyness".
Correction, yes it is. At least, it's one of them.
> I think that all'y'all (thanks Jeff!) are barking up the wrong tree.
It's not the Morph tree that's the problem, it's the enormous bush
that's sitting on top of it.
> Look at eToys.
Ok, let's. There is another way to look at eToys. It *is* the cruft in
Morphic. Of course, as you noticed, people who use eToys, even little
tiny, helpless, innocent children, don't see all the cruft -- that cruft
is there to suit the users of eToys in the first place. It lends itself
to eToys. An intrinsic quality of eToys is that it is designed not to
look like cruft to an eToys user. But then, you could say that about
Squeak Morphic in general: it is designed not to look like cruft to an
The problem isn't what people have put in the subclasses of Morphic.
It's what people have put in the Morphic class: Applications. The
Morphic class (along with the other core classes) is really Morphic +
EToys + Piano Rolls + Stack Morph + Flaps + a few other things that have
suited SqueakC and nobody else, but are not Morphic. In it an unholly
mess, I don't care what language.
Does this mean that eToys is not a great application? No, it does not.
Does this mean I'm not grateful for Squeak? Wrong! Not by a longshot --
I have grown dependent on it for a variety of little applets that I use
on a weekly basis. It's a great smalltalk. It's free. It's completely
open. It runs on a 5.73 bazillion operating systems. I don't use it for
email, for godsakes, but I do use it for plenty of little things.
The problem is not smalltalk, and I don't care if you are the father of
Smalltalk that is saying so (or emphatically agreeing so). There are
plenty of Smalltalks that can be obtained that are nearly cruft free.
Most of them, in fact. They come with lean, mean, code, with tools and
widget frameworks that help you quickly build professional-looking UIs,
if you happen to go in for the whole professional-looking-application
type of thing. Applications that are built, in many cases, by
subclassing and altering frameworks to suit the needs of that particular
application. Applications that are typically built faster then with
other languages, and with less bugs. Applications that do on occassion
collect messy little furballs of code, although said furballs don't
distinguish Smalltalk from any other OOP language. It's not smalltalk --
that's a punt. Morphic, as it exists in Squeak, is, simply put, *the*
messiest UI framework I have ever seen in any language, and it's mostly
*because* of eToys. Factor it out!
The Morphic framework doesn't need cleaning? Just look at this comment
"if oldColor nil, it signals that mouse
had not gone DOWN inside me, e.g. because
of a cmd-drag; in this case we want to avoid
triggering the action!"
This is how SimpleButton, the button that 4 out of 5 squeak programmers
recommend for their patients that use buttons, determines to fire an
event that the user has clicked the button -- by checking whether the
oldColor instance variable is nil. That ain't a problem with smalltalk.
I'm not sure if it is somehow eToy related, but whatever it is, it's
just plain ugly. I dare anyone whose initials are not DI, AR, RA, DW, or
NK to streamline this code and submit a change set, and see if it get's in.
To those that wish to bark up trees, I say Right On! But remember, where
I come from talk + this email (written w/Mozilla) + $1.65 won't get you
much more than a cup of coffee at Starbucks. Bark enough and maybe
somebody will get so worked up that they actually bite on some code.
Sorry, though, talk is about all I can afford, so I'm gonna stick with
Mozilla mail and my little squeak utility apps. Hey, I never tried to
imply that I wasn't a hypocrite...
More information about the Squeak-dev