In edu.uiuc.cs.squeak, "Lex Spoon" <lex at cc.gatech.edu> wrote:

>The ideal solution would be to have the popups when the UI is around,
>and not to have the popups when it isn't.  Perhaps exceptions would work
>for this?  The UI defines special exception handlers for cases like
>file-not-found, and non-UI code can simply catch the exception itself. 

    An idea I thought about for browsing, inspecting, and
    the like was turning the #inspect, #browse, methods into
    messages to command objects stored in a global
    dictionary.

    (Tools at: #inspect) executeOn: self

    The idea being that I could plug the Explorer in and use
    it instead of the standard inspector whenever I did an
    #inspect, or plug the Whisker browser in and use it as
    the default browser instead of the current one.

    I also had vague ideas that this might also help with
    moving some of the Tools stuff out of the core, if you
    held the dictionary in a different namespace and have
    the (is this soft of thing possible?) MVC package load
    in references to MVC tools, the Morphic package load
    in references to Morphic tools, replacing the core
    implementation which would be...I know not what, which
    is where it all falls down of course.

    Perhaps a variation on this approach help with the
    dialogue problem.

    When writing a method #foo where the sender might want
    special error handling behaviour, you'd could first write
    #foo:withErrorHandler: which did the work and then a
    wrapper method which passed in the default command object
    to use for the default case, presumably also picked up
    from a global dictionary so you could globally change
    the behaviour.

    You could of pass in a command that raised an exception
    or set up the global dictionary to have #error: raise
    an exception if that was what you wanted to happen all
    the time.

    But this all starts to sound perhaps a bit too baroque (-;


-- Kapusniak, Stefan e