On Sun, 11 May 2003, Stephane Ducasse wrote:

> 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].

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