At 08:41 AM 1/19/99 -0800, Eliot & Linda Miranda wrote:
>The current scheduling policy of being co-operative within a priority
means that UI developers have been able to ignore thorny thread safety
issues.  This is one of the reasons the Squeak/Smalltalk UI has evolved so
fast and so interestingly. Think hard before you introduce the complexity
of a thread safe system.
>

Hmmmm. To me this sounds like all the new architecture being put into
Squeak is being tuned and judged for "goodness" in an environment that may
not match the reality of current UI expectations. Wouldn't it be better not
to ignore the multithreading issues but to come up with architectual
solutions that make things easy? By belief is these are thorny issues only
if the underlying architecture is wrong.

To me, one of the prime design goals of new UI's should be they are never
"stuck". The user should ALLWAYS be able to interact with the UI, even if
it's to tell the system to never mind about that operation you just
requested. Note that UI's almost never seem to fully achieve this. My guess
is becauce the underlying architecture makes it really hard to "do the
right thing from a UI perspective". Having an "undo" facility deeply
embedded in the system architecture could help.

As I remember, one of the major benefits of using a multiwindowed UI was to
avoid being forced into a "mode". Seems like the Blue Book talked about
what a vile concept "modes" were. At ANY moment, the system should be
responsive to your new input. Being frozen and unreceptive to input is
simply not ok. I agree that in some cases the system may have to respond
back and indicate, "I can't stop" or "I can't undo that" (for example,
selecting doit on Smalltalk := nil. might be hard to undo). Many cases like
this could give status feedback (like "Please wait just a moment longer,
we're only 34% done querying every web site on the Internet"). 

I could even imagine some VM facility that nicely informs the user their
program/system is no longer responsive to UI input ("Unhandled program
exception at 0x34582512" was not what I had in mind). My memory is the old
DEC VAX 780 also came with a PDP-11 to act as a supervisor computer. If the
OS or hardware failed, the PDP-11 would take over, scavange thru the VAX
memory, and try to get as many thing going as possible again. Having a
parallel VM/VI in Smalltalk, ready to spring into action on serious system
failure, would be similar. This VI could be extreemly reduced in
functionality, but still fully extendable via the normal tools.

I like the goal of ALLWAYS having some part of you computer keeping it's
sanity, even if your hardware breaks, or other parts of the system totally
fail. I remember magazine ads for I believe the QNX operating system vs.
Windows. The ad text said something like "John reboots his computer every
week, and Frank hasn't rebooted his computer since 1992. Which OS do you
want to be using.".

I want to give high praise to the folks making Squeak possible. I also want
to gently push them, and us, to be creative in making systems better than
we ever thought possible. It would be nice if in 20 years, you ask someone
to "reboot" or "interrupt" their computer, and they look at you puzzled by
what on earth your talking about.

- Jan


___________________________________________________________________
            Paradigm Matrix Inc., San Ramon California
   "video products and development services for Win32 platforms"
Internet: Jan Bottorff janb at pmatrix.com
          WWW          http://www.pmatrix.com
Phone: voice  (925) 803-9318
       fax    (925) 803-9397
PGP: public key  <http://www-swiss.ai.mit.edu/~bal/pks-toplev.html>
     fingerprint  52 CB FF 60 91 25 F9 44  6F 87 23 C9 AB 5D 05 F6
___________________________________________________________________