On Feb 9, 2005, at 10:37 AM, Cees de Groot wrote:

> On Wed, 9 Feb 2005 13:09:40 +0100, Avi Bryant <avi.bryant at gmail.com> 
> wrote:
>
>> Along those lines - I'm not sure how wxSqueak handles this, but
>> Seaside definitely needs  "UIManager default" to be some form of
>> dynamic variable (process-local, or walk the stack), rather than a
>> global.  I'm surprised Tweak doesn't need that too; don't you have
>> cases where Morphic is running in one scope and Tweak in another, and
>> you'd want to pop up the right dialog depending on where you were when
>> you sent #inform:?
>>
> More complicated than that. I want "self inform: 'foo'" to pop up a 
> dialog in whatever environment is running (process-local, probably); 
> but "'foo' inspect" to pop up a dialog in the environment I as a 
> developer told the system I like. So no Seaside inspectors if I'm 
> quite happy to go to my image's window and do the inspect there...

I'm pretty happy with the multi-UI solution I came up with for 
OmniBrowser. It uses Notifications to request user interaction.

For example, when you call #confirm: it raises an 
OBConfirmationRequest. The default action on that exception is to open 
a Morphic PopUpMenu with 'ok' and 'cancel' items, and then #resume: 
with true or false depending on what the user selected. There are 
similar notification classes for opening menus, FillInTheBlanks, and 
browsers.

I think if we can generalize this so that the default action isn't "use 
Morphic," we can get what we need in a pretty clean way:

* Dynamic scope: multiple UIs can run concurrently as long as they're 
in separate Processes.

* Ability to easily intercept UI requests and deal with the 
programatically. The OmniBrowser tests
   do this to simulate user actions. You might also want to do this when 
scripting things
   that would normally done by a user - installing a bunch of stuff from 
SqueakMap, for example.

* Ability handle different types of interactions in different ways. 
Different notification classes can implement
   different strategies for deciding which UI to use. So 
developer-oriented UI like inspectors and debuggers
   can appear in a different interface from user-oriented UI.

For my 2 bits, I applaud Andreas for turning the discussion in this 
direction. He's absolutely right: who cares what the "official" UI is 
if we can all use which ever ones we want?

I'll commit to making OB multi-ui-enabled, and pitch in whatever help I 
can give to task force with one caveat - I'll be offline next week, so 
I won't be able to contribute much in that time.

Colin