The "linux guru" insult may perhaps have been aimed at me,
since I provided the detailed list of "but Squeak _does_ have X".

I should perhaps make it clear that when it comes to UI programming
in Squeak I am very much a beginning myself.  I spend a lot of time
staring hopelessly at non-existent class comments wondering what to
do, and I must say that I still regard the material in the Squeak
books (including for example chapter 2 of "Open Personal Computing
and Multimedia") as *utterly inadequate*.  Don't get me wrong, they
are a good start, but ONLY a start, and do not really take you very
far.

My point was not to dismiss the original poster's concerns, but to
explain that the problem isn't what he thought it was.

Squeak DOES have an extremely powerful drag and drop GUI building
kit.  It's called Morphic, and there's more in it than I could ever
have imagined.

What Squeak DOESN'T have is documentation.  Ideally, not only would
every class have a class comment, but the class comment would contain
a link to a tutorial.

As a fairly clueless sGUIker, I don't go around saying "Squeak doesn't
have <whatever>."  I go around saying "It only took me a few seconds
to find out that Squeak DOES have <whatever>, but now I don't know how
to use it".

Just at the moment I'm having real trouble using PluggableListMorph.
Here's what I want to do:

    I want to record the time I spend on various activities,
    and I want to make collecting that information as painless
    for myself as possible.

    So I want to have a box with buttons in it.  Whenever I switch
    to a new activity, I want to press one of the buttons.  This
    should record a stop time for what I was doing and a start time
    for what I am about to do.  Obviously switching to another
    project should result in selecting the "Pause" activity.

    The obvious thing is to have a TimeRecorder object which has a
    collection of activity names, a current activity, a start time
    for the current activity, and a total time for each activity.
    It should also hold a PluggableListMorph, which should call back
    to the TimeRecorder to get the list, the current selection, and
    to set a new selection.

I know that the project-changing bit can be done, but decided to put
off worrying about that.  The problem is that
    - the list is transparent
    - the PluggableListMorph is way too big for its contents
    - the highlighting doesn't change; when I click on an item it
      _is_ selected, but that doesn't show up on the screen.
    - it's ridiculous for a five-element list to have a scroll-bar,
      but I've no idea how to make it go away.

I can fix the transparency by manually setting the colour,
but surely the default background colour for a list should be opaque?
Transparent works when you are adding a list to some other morph such
as a Browser, which can supply the background colour.  It does not work
when you want a free-standing list.

I can fix the size by manually setting the extent, but that feels wrong,
and it is NOT AT ALL OBVIOUS what to do.  (This is where the class
comment should help, no?)  #resizeToFit and its relatives only apply to
PasteUpMorphs, and a PluggableListMorph isn't one.  #resetExtent: looked
promising, but whatever it does, it's not what I want.
At the moment I'm doing
    morph position: 0 at 400.
    morph extent: "a guess"@(labels size * 13).
but the extent should depend on the morph's font.  Most of the uses of
PluggableListMorph in the system seem to assume that you have a lot more
items than will fit and they drop the list into an existing morph in
some specified "frame".  That's great for lists that are embedded in other
morphs, it is NOT good for free-standing lists.

I can fix the no-highlighting problem by adding
    self update: getIndexSelector
at the end of #changeModelSelection:,
but surely I shouldn't have to _patch_ a list morph to make it do
highlighting properly?

I thought I could "fix" the scroll bar by deleting it, but Cmd-click
won't select it.  I'm including this one as an example of where Squeak
_does_ eventually help the persistent beginner.  I opened an Explorer
on the PluggableListMorph and discovered that there is a
'scrollBarHidden' instance variable.  Asking about 'inst var defs' in
a Browser and choosing 'scrollBarHidden' as the variable of interest
told me "There are no Stores into scrollBarHidden" which is not as
helpful as it could be.  It had to be in ScrollPane, and as soon as
I opened a Browser on ScrollPane, #hideScrollBar stood up and waved at me.
In fact I think I want #hideScrollBarIndefinitely, which was next to it.
Yes, that worked.  It took a bit of persistence to get there, but I _did_
get there, and so could anyone once they'd learned the navigation tools.

The bottom line is that on the day that I decided to do this, I _was_
able to do it, but met with some frustration on the way.  In retrospect,
the problems mostly stem from a single cause:

    Most system uses of PluggableListMorph want to drop a list into
    a specified portion of an existing window, but I wanted a
    free-standing list.

Even if there _had_ been adequate documentation, it would have been
documentation adequate to the task of using a PluggableListMorph inside
some other morph, not to what I wanted.  Perfection will always elude us.