Avi Bryant wrote:

>No, per project/image is not enough.  One image can be used
>simultaneously from multiple UIs at the same time.  For example, I'm often
>using at least two of these at once:
>
>- REPL command line
>- Web UI
>- Morphic UI
>
>Having the Web or REPL UI lock up because Morphic is presenting a
>FillInTheBlankMorph is really annoying.
>
>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.
>
>I actually think we should go further with this, and have at least
>Sensor and Display be per process as well.  
>

This is exactly what I wish someone would do with DynamicBindings (as 
I've said a few times before)...it wouldn't take much work at all.  I 
should also mention that DynamicBindings owes much of it's design to 
input from Avi and Anthony Hannan on this list.  DynamicBindings really 
just builds on the exception handling mechanism and facilitates 
propogating variable bindings when forking processes.  I've recently 
been using the following convention for accessing dynamic bindings 
(shown using Sensor as an example):

EventSensor class>>current
     ^ #'EventSensor.current' binding

EventSensor class>>current: anEventSensor
     #'EventSensor.current' binding: anEventSensor

In this example, rather than refer to the global 'Sensor', you would use 
'EventSensor current'.  The io process might look something like:


EventSensor>>ioProcess
    "Run the i/o process"
    | eventBuffer type |
    EventSensor current: self.
    eventBuffer _ Array new: 8.
    [true] whileTrue:[
        [self primGetNextEvent: eventBuffer.
        type _ eventBuffer at: 1.
        type = EventTypeNone] whileFalse:[self processEvent: eventBuffer].
        inputSemaphore waitTimeoutMSecs: EventPollFrequency.
    ].


>Combined with Colin's
>native-Squeak VNC server, for example, this could lead to some very cool
>possibilities.
>

Yes, indeed.

- Stephen