The problem can be circumvented by deferring:

fork { defer { ScIDE.prSend(\mute) } };

So essentially, the IDE has to be called from an AppClock thread. If this is true, then prSend should probably be doing this internally.

Alternatively, it should throw an error.

So if correct it should probably throw something like 'ERROR: Qt: You can not use this Qt functionality in the current thread. Try scheduling on AppClock instead.'

So could add something like this to ScIDE_Send:

if( gMainVMGlobals->canCallOS ) {
        error("You can not use ScIDE:prSend functionality in the current thread.\nTry scheduling on AppClock instead.\n");
        return errFailed;
    }

Not sure if this is better. I don't think deferring implicitly could cause any unforeseen side effects, but...?

I don't think deferring implicitly could cause any unforeseen side effects, but...?

The main problem is that you end up implicitly deferring somewhere inbetween, in particular when it is done with MVC, like the changed calls on server: one shouldn't have to defer recording calls just because somewhere down the chain it updates a GUI, no?

So maybe the cleanest place to do the deferrals in is in the ScIDE response to the notifications.

But it is a bit endless:

fork { Server.default = <some new server> };
e.g.
fork { Server.default = Server.default };

Also this will throw an error (now just breaks).

one shouldn't have to defer recording calls just because somewhere down the chain it updates a GUI, no?

No. To be honest though, I don't really know precisely why there is a problem with this in this case. Perhaps someone can clarify.

In Server:

*default_ { |server|
        default = server;
        if(sync_s) { thisProcess.interpreter.s = server };  // sync with s?
        this.all.do { |each| each.changed(\default, server) };
    }

The changed signal calls

*defaultServer_ {|server|
        serverController.remove;
        serverController = SimpleController(server)
        .put(\serverRunning, { | server, what, extraArg |
            this.prSend(\defaultServerRunningChanged, [
                server.serverRunning, server.addr.hostname, server.addr.port, server.unresponsive]);
        })
...

Which is victim to the bug above.

I mentioned this example only to show how far fetched the chains can be.

I think your original idea is sensible. Just get the ScIDE class to do it itself.