Thanks to all who replied.

Eddie Cottongim:

[liberally snipped]

> ... Morphic has been around for a
> while now, and there isn't much excuse for such a serious kink to exist
> despite several available patches and extensive discussion in the past.

I have some sympathy with a design which says that (almost) everything is a Morph, and CPU be damned.  When it comes to the UI, I really don't mind if opening a window takes 0.1s rather than 0.01s.  But when it takes >5s (on my ancient 400MHz PC) to view the class Morph in the WhiskerBrowser, I'm losing time and my train of thought!

>     a) ScrollPanes draw every submorph, not just the visible ones. Yes,
> StringMorph has an early out, but the performance remains O( total items)
> instead of O ( viewable items).

When I found that not much intelligent use is made of the clipping rectangle (here and elsewhere) I was a little perplexed.

> Given of List of n items, where k are viewable at one time, the scrolling
> performance can be as good as O(k), ...

... and the constant can be very small if BitBlt is used in line-at-a-time scrolling.  This was something else which surprised and disappointed me - the (apparent) lack of hard-scrolling support for Morphs in general.

> I remember some people being mad that Java's Swing was slow with more than
> 20,000 menu items.. I'm not that picky! But 20,000 list items is a real
> possibility.

Well, I would hope that I wouldn't hand a user a list of 20,000 items without some very powerful shortcuts to get to all of them, starting with initial-letter keystrokes.

I am perfectly comfortable with writing classes which provide speed-ups, or even withrewriting kernel code where necessary.

If I dared to criticise the wonderful work which has been done to get Squeak to where it is now, I would say that the development seems to have been following the slogan, "Never mind the quality, feel the width!"  I don't really need voice synthesis for my current app. :)  What I do need are fundamental tools which are small, fast and easy to drive.

A couple of things surprised me about Squeak as I started to explore it:

(1) Most methods do not have a comment.  (Class comments are new to me, but many classes seem to be missing comments too.)  I'm used to almost every method (except maybe new, intialize and instvar accessors) containing a comment which starts "Answer a [classname] which ..." or "Answer the receiver.  [Does something]" or similar.  It seems to me that we need an "MCP" - Method Commenting Project". ;)

(2) Many naming conventions of Smalltalk (as I understand them) are not followed.  I was shocked to see "evt" used instead of "event" or "anEvent".  I thought the Smalltalk way was to write complete words.  I also thought that parameter names (and parameter names only) traditionally start with "a" or "an".

Now of course my concerns mean I should never be a Harvester, because I'd reject any contribution which did not conform rigorously to these standards and others.  Too many people like me in the past would have meant today's Squeak would provide classes and methods for little more than adding and subtracting SmallIntegers. :)

Cheers, Paul