Hi

I do not feel really good for assessing your design.
But I have some questions to help evaluating it:

- How many of different interaction do we have?
	I do not think that we have that much
- what is the frequency of having new interaction?
	I think that this is rare that we have new ones (but I can be 
completely wrong)

>> For me what I would really to see happening is a clean of the
>> inform: ..... to generate exception that UI clients could catch.
>
> I've started work on this.  It's not completely obvious what the 
> design of
> this facility should be.  The simplest would be something like this:
>
> - define a "Dialog" protocol with methods like #inform:, #confirm: ...
> - define Object>>inform: to be something like this:
>
> inform: aString
>   CurrentDialogNotification signal inform: aString
>
> - set up handlers for CurrentDialogNotification that provide an 
> instance
> that responds to the Dialog protocol:
>
> [...] on: CurrentDialogNotification do: [:n | n resume: MyDialog new]
>
> The advantage here is the relative simplicity - we only need to 
> introduce
> one new exception class, along with implementations of Dialog for 
> Morphic,
> MVC, etc.  Adding new UI interactions is quite lightweight - just add 
> new
> methods to the Dialog implementations.
>
> Another possibility is to define an exception class for each type of
> interaction.  #inform: would look like:
>
> inform: aString
>   (InformUserNotification message: aString) signal
>
> It's possible we could make things a little more general and have one
> exception for message boxes (with configurable buttons), one for text
> input boxes, and so on.    But there would still be a fair number of
> exceptions, and adding an interaction would mean adding a new exception
> class.
>
> The advantage here is that it's possible to catch any individual one of
> these without affecting the rest of the UI.  For example, in an install
> script you might want to ignore any simple messages, but still have
> progress bars show up - so you could do something like
>
> [...] on: InformUserNotification do: [:n | n resume].

I have the impression that we do not really want that.
Others?

> What I've actually done so far is a hybrid of this approach - I define 
> an
> exception for each interaction, all of which are subclasses of
> UserNotification.  I've then defined UserNotificationHandler classes 
> that
> catch any UserNotifications, and then call a particular handler method
> using double dispatch through the notification.  This way, generally 
> what
> you have to do for a new UI is define a new Handler subclass and 
> implement
> the #handleFooNotification:, #handleBarNotification: methods - but it
> would still be possible to catch individual exceptions in special 
> cases.
> However, this all feels a bit heavyweight and overdesigned.
>
> Any comments?
>
> Avi

What I like is that we could remove all UI dependency from the kernel.
Now I still do not really see where the handler for Morphic would be 
defined?
In some UISession (if I remember the class proposed by the SqueakMod 
guys).

Stef