Tim Rowledge wrote:
> What is going to happen if your loading and coding clash? What if
> the loading code needs to be done in some atomic manner (perhaps it
> affects how the text views you are typing in work) ?

Thinking on this some more, it seems to me that a nonblocking update 
stream isn't much different to the current setup in this regard - except 
that if it all was going on in the background it makes the 
window-of-UI-inaccessibility smaller for the user. Or at least, please 
correct me if I'm misunderstanding or oversimplifying:

I imagine that in the current system, if an update needed to completely 
replumb the UI it'd have to destroy and rebuild, or at least temporarily 
take away or hide, the UI objects visible onscreen.

Wouldn't it work to allow the user to keep working right up until it 
needed to take the final UI-rebuilding action? Mid-typing-a-sentence, 
the widget could warn me that I'll be interrupted for 20 seconds or so 
while the UI is rebuilt. My window would either let me save before being 
destroyed, or would just vanish and then come back in updated form with 
all my work preserved.

(I noticed a thick red border on my code pane turned up when I made an 
incompatible change to a method in the background once - so it looks 
like there's already some provision for avoiding gratuitous loss of 
work...?)

Tony
-- 
  [][][] Tony Garnock-Jones  | Mob: +44 (0)7905 974 211
    [][] LShift Ltd          | Tel: +44 (0)20 7729 7060
  []  [] www.lshift.net      | Email: tonyg at lshift.net