Lex -

Thanks for the great comments!

Lex Spoon wrote:
> Most of your proposal sounds great 

Thanks.

> (except that if I could personally afford
> to pay someone to develop squeak stuff, I'd probably pay myself :)).  

I wish I could afford to do it for free myself.
I blew all my money on writing a GPL'd garden simulator. ;-)

>I have issues with a few of your issues, however:

Fire away!

> The current fonts are for all practical purpsose free, right?  Now maybe
> we need *better* fonts, but that's a different issue.

Someone correct me if I am wrong, but I still thought there were fonts
in Squeak from the original distribution. The license prohibits
redistributing the image with those fonts if for commercial use. I may
need to look into this more. I know there was a discussion of PD fonts
months ago, but I did not think the original Apple fonts were completely
eradicated.

> > * command line scripting,
> Squeak already has this.  "Squeak myimage.image myfile.st".  Now it
> could be more *useful*, but that seems like a different issue.

True. What I am talking about here is utility and footprint. When you do
"Squeak myimage.image myfile.st" you startup a system that creates an
internal display (taking memory), sends errors to internal popup windows
(causing hangs), and so forth. To be really practical, the interaction
with the command line needs to be rethought, and this includes delving
into some rewriting of error handling (i.e. a dialog is never popped up,
and likely remote debugging via a TCP/IP socket connection). 

Also, startup time needs to be minimized, in part by having the minimal
image needed for only text processing. A command line Squeak optimized
for text handling should ideally have a <100K image and a <300K total
memory use (optimistically). This could likely be accomplished by only
including the compiler, some standard common classes, simplified error
handling, and file handling stream code. This command line image could
load other things as needed (debugger, network code, graphics code,
etc.) like Python does.

> Also, I don't think Squeak's biggest selling point is scripting, anyway.
>  Even for an app that is ultimately headless, I'd generally prefer to
> use the GUI to *develop* the app.

Good point. I agree most script development would be done in the Squeak
environment, probably with a "virtual" command line for testing. 

However, scripting is what is "selling" Python, Perl, TCL, and even Java
(since Java's major success seems to be only for servlets at this
point). So, I think Squeak's "market penetration" could benefit from
this sort of improved support.

> > * VM GUI events (maybe), and
> 
> What do you mean here, exactly?  Morphic uses events for most
> everything.  If you are talking about having the VM pick up mouse click
> events instead of polling the mouse state, well, that would be nice, but
> it hardly seems like a critical issue for most people.

When I was pouring through the Squeak code years ago for the (now
defunct) Squeak->Newton port, a major issue was polling done by Squeak
for mouse location and buttons, which is needed by MVC apps, and could
not be reasonably supported by the Newton. Most modern Smalltalk systems
use events, not polling. While it is true that Morphic supplies events
(a good thing), at the top, Morphic is polling away as a MVC window, and
then generating events. I think that needs to be fixed, and ultimately
changes need to be made at the VM level for efficiency. This could mean
a boost in speed and responsiveness (I hope). But you are right, perhaps
it is less critical than other issues.

Thanks again for the input. I've had several private emails about
Squeak/Pro and there is a surprising amount of interest -- and even
$1000+ pledged so far. Some ideas are being bounced around as to what
would make a more interesting proposal -- one thing under consideration
is making pledges equal to purchasing support contracts in advance.

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the open source Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com