Steve,

I sincerely wish you luck in your efforts to use Squeak.  Free advice is worth everything it costs: here some more proof :)

Native Widgets?
=============
Far be it from me to stand in the way of Squeak's growing a good connection to native widgets, but I submit that it is not all that essential, and would in fact be a step backwards in some ways.  However, if it is an option with no overhead when it's not used, then it's a good thing.

Why am I soft on native widgets?  First, native widgets are external entities which therefore require external interfacing to make them work.  At least on Windows, the interface to them is (somewhat torturous) via the message queue.  Well-crafted Smalltalk code is likely to be faster, and will be much easier to optimize.  The productivity of the Smalltalk development environment will lead to programmers' having time to optimize the code.  Also, one can "cheat" a little to make the widgets more efficient in one situation without compromising more generic callers.  Obviously, non-native widgets can be inefficient and buggy too.

One thing that is very(!!!) important, and IMHO _greatly_ under appreciated by the Squeak community (sorry gang, just calling it how I see it) is the FEEL of the user interface.  My experience is that users don't know widgets/controls/etc. when they see them.  They see "screens", and they don't much care how things look, as long as they are: (1) not ugly; (2) somewhat intuitive; (3) responsive.

>From my perspective, please add that some appropriate modality is necessary to keep users out of trouble.  I would frequently rather have three or four questions presented on one dialog with reasonable defaults than need to deal with a succession of menus.  Many users are simply too distracted and "innocent" (ok, stupid<g>) to be trusted with the ability to open lots of non-modal dialogs.

I work with an RN who, to an untrained observer, could be mistaken for a glorified typist for a good fraction of her time.  In fact, she is a trained professional who makes substantive judgements while she is "typing".  She has long made it very clear that she wants to tab around on one of my creations.  She does not care about the "look"; she very much cares about the "feel".  BTW, she is about to get her wish, but that's another story.

What would I suggest you do?  If native widgets are a requirement to you, then have at it.  The Cheese project did it (to what extent I am not certain) on OS/2.  You might want to look at http://www.wxwindows.org.  Please look at Zurgle.  Zurgle is a remarkable effort, and if it does anything wrong, it would emulating the XP interface rather something simpler.  

Regardless of the mechanism, I suggest that you address the feel of Squeak's user interface first, and then worry about the look.  If you tackle both at the same time, fine, but it's the feel that is hurting, and the feel that is the most difficult for an isolated developer to fix.  My second priority would be to have more pluggable control over the look of the Squeak widgets, and finally, to select and assist/pressure one of the projects that is creating a more complete widget set (though I suspect that will be easier when the feel is fixed and the looks are better factored).


Modularity?
=========
Some of your post suggests to me that you envision Java or .NET programmers being able to script the smallest of eToy objects in your Squeak image.  While I am not suggesting that this is impossible, it is something that, like native widgets, sounds better when it's requested than when it's delivered.  The problem with scripting from outside languages is that the interfacing details are a big problem.  Static language programmers are so accustomed to header files and function prototypes that IDL etc. does not seem burdonsome to them.  However, at least COM's IDL is even more problematic than C/C++ headers - not only must you describe the pointer type, you often (perhaps always??) need to specify the length of the array to allow marshalling of the data!  It gets worse, and the details become so punishing that revisions do not occur, and poor designs get foisted on developers and end users.  

If you are planning to "sneak" Smalltalk into Microsoft and Norton by telling them they can connect to everything, you might run into problems.  I have no desire to discourage you, but it is important to recognize that Smalltalk can be a tough sell.  I used the forgiveness/permission uncertainty relationship combined with delivering things that people later had to admit would never get done any other way.  It took some time, but my department gets it now.  You might not have the freedom to do that.

I will close by saying that every time Microsoft "leaks" (releases) screen shots of another OS, it looks ever more like things that were done in Morphic years ago.  Looks change; match their feel (if only as an option) and Squeak will become more accessible to developer's like yourself.

Good luck!

Bill



Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: bills at anest4.anest.ufl.edu
Tel: (352) 846-1285
FAX: (352) 392-7029