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