Andreas,

====================================
> we could use this kind of 
> refactoring to separate the "Morphic" programmers use to build boring 
> old applications, from the "Morphic" that's perfect for eToys. 

Nothing personal, but as of now, this is the most frustating message I have
seen in this thread. Don't you realize that the Morphic that is perfect for
eToys *is* the one that is perfect for programmers?
====================================
I agree that eToys is a good interface for some tasks.  It would be horrible for other jobs.  One of my "cash cows" is a system that bypasses Dolphin's ViewComposer, allowing me to create a system that creates and configures hundres of widgets based on meta data.  The different views are created lazily, so the user only waits for construction of what they actually open, but it all has to be created and tied together at some point.  

I am undecided at this point whether eToys is the Squeak alternative to Dolphin's ViewComposer.  It seems like some projects to create something like the latter have stalled.  Perhaps the authors discovered that they didn't need the tool, or maybe they decided to leave Squeak entirely.  Any hard facts on that point?

You might see these issues differently if you had to put up with my users - sorry, I meant to say "if you had the privilege of working with my users" :)  Both statements are valid.  I deal with very intelligent but often not technically savy people who can find themselves in extreme circumstances with very little warning.  Something so mundane as a modal dialog box is crucial to keeping them out of trouble - their minds are on the tasks, and the computer is supposed to be helping and coaching them, not coddled by them.  Give them something non-modal, and you'll soon find five or six of them open in various states of completion..  A sequence of menus and prompters will frustrate them - they want to see the kinds of choices they are going to face without having to answer a bunch of questions to decide it's not really what they wanted to do.

If that sounds like a plea for native widget support, it's not.  In fact, I've had to devote quite a bit of work to creating emulated widgets for various reasons.  However, there is a somewhat standard "vocabulary" of user interfaces, and despite the fact that many users don't know a control from a window from a dialog box (I hear the term "screen" a lot), they know when something deviates from the norms.

Zurgle might be overkill in some ways, but it did wonders to punch up many appearance issues for Squeak.  I would have chosen the Win2k look vs. XP, but if it is difficult to change title bars, etc., then some refactoring to make that easier seems warrranted.

However, Squeak's feel is much more of a problem than its look (which has improved quite a bit over time).  My favorite example is how clicking in just the wrong spot will pick up an entire system window, bypassing the quick redraw and resulting in very sluggish behavior - especially on slower machines that I often need to target.  

Appologies if this adds to your frustration.  I'm going to have another look at Bob's UI, but it seems to me that in addition to providing an excellent simulation environment (which is really how I look at Morphic), there is room for a fast and robust widget set that will blow the doors off of most native widgets, and will aid in writing the boring kinds of programs that are often important to be able to write.  That widget set should be readily accessible from some kind of GUI editing tools, as well as being friendly when programmatic assembly is the best option.

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