You raise exactly the sorts of issues we're talking about. As another
example, some process will be driven by different "clients" - sometimes
with a user attached, sometimes guided by a script. So an oracle
answering, for example, installation questions without a GUI is also
useful.

To sharpen the different issues we have -

While Views separate display from the model (allowing configurable, and
multiple views on the model (a one way effect)), and Controllers allow
different reactions to user requests (one way, user initiated requests),
this discussion is about requests for information initiated by the
running process, which is not supposed to know who it is asking (user,
install script or whatever).

Since most interactions between UI and application model indeed start at
the UI, which is naturally configured for the model, and not the other
way, this has not been so urgent to address until now.

Daniel

Anthony Adachi <adachipro at yahoo.com> wrote:
> 
> Stephane Ducasse wrote:
> 
> > I would not do this change. I imagine that we should
> find a much clever
> > way of notifying user. Avi suggested to me that we
> could have exception
> > that would be caught and letting the used decide if
> he wants to put a UI or not
> > for headless image for examples.
> 
> Tim Rowledge then wrote:
> 
> >  The key item to separate progress notification from
> >  needing the UI
> >  classes is to change the defaultAction to do
> nothing
> >  rather than display
> >  the progress bar (well, modulo the stuff to make
> sure
> >  the block runs
> >  etc). Then one has to find all the place where the
> >  exception could need
> >  to be handled (which is actually pretty tricky and
> >  tedious - tools
> >  would be good here) and handle it the right way.
> 
> Avi Bryant wrote:
> 
> >The only way to do it right is per process, and the
> cleanest way to do
> >that is probably to do exactly what Tim suggests,
> which is to have a
> >Notification subclass signalled for each type of user
> interaction -
> >#inform:, #confirm:, progress, etc.
> 
> First, I should note up front that I'm new to Squeak
> and don't know much about it's inner workings so
> please feel free to ignore my opinion.
> 
> Wasn't the concepts behind MVC suppose to be about the
> separation of the interface and the model? By the way,
> I realize that Morphic isn't MVC (I'm speaking of the
> motivations initially behind Smalltalk's MVC at a
> conceptual level). Also, I have read somewhere that
> MVC originally had 4 elements Model, View, Controller
> and User. Of which User being the consideration of
> whom is the end user and their needs.
> 
> Many people seem to think of View and Controller being
> some sort of GUI elements but originally was not this
> concept meant to be whatever mechanisms were
> appropriate to the end user? 
> 
> For instance, people with handicaps may have different
> needs in how they control or view the computer. A
> quadriplegic cannot control the computer with a mouse
> or keyboard and a person with a visual disability will
> have difficulties with a "View" which is a Graphical
> UI.
> 
> Also, what if someone is perfectly able visually but
> doesn't need a GUI? Like perhaps if they desired to
> run Squeak as a server? In such cases perhaps the
> "view" they would want would be a record of some sort
> on how long certain time consuming operations took.
> Perhaps, in order to keep tabs on performance or to
> monitor regular occurring events such as how long
> periodic backups took. e.g.-perhaps in the form of
> some kind of log file (either saved inside the image,
> on disk or to be part of a summary of notable
> activities emailed out on a regular basis)? They may
> not even wish to have Progress dialog windows
> popping-up at all. 
> 
> Again, what about people who are blind? Obviously, a
> GUI progress bar is rather useless to them and would
> be in need of some other form of progress notification
> other than visual. i.e.- a different form of "View".
> 
> I think the key words here are notification ... of
> progress.
> 
> Maybe messages intended for View like things should be
> sent to a collection of Observers? Observers of
> pertinence who can be attached or removed from the
> notification mechanism. (i.e.- as in GoF Observer
> pattern or similar). Observers who respond in a way
> appropriate to the needs of the end User.
> 
> Just a thought which came to mind.
> 
> Take care,
> 
> Anthony
> 
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo.
> http://search.yahoo.com