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 
eToys user.

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 
from SimpleButton>>mouseUp:

    "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...