Hi!

Larry White <ljw1001 at gmail.com> wrote:
> Thanks for your help but, No. Smalltalk does not make such things easy. It'=
> s
> almost like someone is taking a perverse pleasure in making such things
> hard.  Here are some of the most obvious problems with loading code:

Hehe. :)

> 1. I should be able to load the file from the "File List" browser.  This is
> a close as Squeak comes to a file menu, which is a universally accepted
> approach to loading files into desktop software.  And if I highlight a file
> and the Load button appears, then it should actually load when I click it.
> If it only loads some of the file, I should get an error or warning message=
> .
> (Fortunately, I've used Squeak before, so I can actually find the file-list
> dialog.) I highlighted the mcz files, and it indicated that they loaded.

In some ways Squeak can be viewed more as an OS than a single app. So
given a full OS there are many ways to open/load files. :) But sure,
things can be more streamlined, and there are people working in those
directions.
 
> 2. There shouldn't be 3 or more ways to do the same thing: I count file-in,
> install, monticello, and package loader. For all I know, there may be more.
> Ironically, this is the same problem OO is supposed to solve - hiding
> implementation differences behind a simple, consistent interface. I don't
> need 5 different buttons/dialogs to load different file formats into Excel.

Well... a few comments explaining the "whys" (but not necessarily
defending it):

- "file in" is historical. It only works for .cs and .st (I think),
which is plain source.

- "install" is slightly different - it actually creates a new changeset
first before filing in. It should probably be called "file into new
changeset". I am writing from memory here, so I may be wrong.

- Monticello is a tool that has plenty more operations than just
"loading". The Filelist today has a service registry etc, so things are
actually streamlined a bit. But a "generic" load button would be nice
perhaps.

- The package loader doesn't even have a mechanism to open a file from
disk. :) It downloads from the net etc. And yes, it handles a multitude
of formats under a single "install" menu option. Exactly what you want.
:)

So the thing to note is that you can't really compare with "different
file formats" - we are in fact talking about "different operations".

> 3. A tool for loading code shouldn't be called Monticello, it should be
> called, I dunno, maybe,  code-loader or something equally descriptive. A
> browser for a virtual tour of Thomas Jefferson's house should be called
> Monticello.

It is an app. Apps have names. Not all word processors can be called
"word processor". :)

> 4. The instructions for using monticello shouldn't refer to mouse buttons a=
> s
> red and yellow. Yes, I know it's a Smalltalk tradition dating back from the
> days when the community actually cared about usability. My mouse buttons ar=
> e
> both black. Give me a break.  (This is where it starts to feel like poor
> usability has crossed over into sadism.)

Hehe! Well, I can't really comment on that, I agree that colors for
mouse buttons isn't really helping today.

> 5. It can't be usable if it doesn't work. I downloaded the files to a
> directory, opened monitcello, browsed to that "repository" highlighted the
> files and clicked "load". Same as before-says it's loading, but no new
> classes/methods appear in the system. Hmmm, maybe I should have clicked
> Merge. I click Merge. It says it's reloading and hangs. Maybe the firewall
> is blocking.  Monticello must use HTTP tunneling, right, so the user doesn'=
> t
> have to deal with networking stuff?
> 
> And then, inevitably, somebody from the mailing list shakes their head and
> tells you it's easy to use.

Mmmm, not sure, but if it said it loaded it - are you sure you didn't
get something? People often have problems with HTTP on non standard port
numbers, like 8888 (IIRC the Kilana url was such a port, right?)
  
regards, Göran