> When loading a big package (Seaside in this case) it's very obvious that something is a bit inconsistent wrt the progress bar. Most of the time it sits at the centre of the screen but every now and then it leaps (is it a bird? is it a plane? No, it's superbouncyprogressbarman!) to the cursor position - and then back. All a bit travel-sickness inducing really. Clearly there's no very good reason for a UI element to do this dance of flickeriness.

I think a change I made years ago is responsible for that mess.  We
should definitely fix it some way some how...

> As best I can tell the bouncing is caused by a conflict between a plain String>displayProgress... where the position is nil and thus defaults to screen centre, and MetacelloSqueakPlatform>>#do:displaying: which specifies Sensor cursorPoint. There are reasonable arguments for both choices (screen centre is consistent, cursor location is 'where user is looking') but mixing them is not so desirable. There's also a practical issue with using the cursor location in that there is a pretty good chance that whilst loading is happening the user may be looking at other host windows and the cursor location value will the leaping around. I'd suggest that it might be nicer to make the progress bar stay where it was initially opened, even when new levels are added as packages load packages and so on. Does anyone have strong opinions on this?

+1.

> Something related in the UI sense is that we can get nasty confluences of several dialogues/notifiers/etc apppearing in a stack at the screen centre. This came up recently when trying to explain to a non-user (and one that really, really, wanted to find reasons to disparage Smalltalk) how to load some code and it appears that an rather important notifier had got covered by a progressbar - they seem to insist on being at the very front.; result, one very annoyed user and some tricky remote-by-email-debugging. I'm not entirely sure what a good answer would be for this. One relatively simple option would be to default the position of some of the popup windows a bit differently so they don't obscure each other so completely. I suppose one option would be to make popup dialogues add to the progressbar if it is open - in the same way that we get a stack of progress bars, add the inner morphs of a dialogue?  I really don't know a solid answer for this, but it certainly isn't a good thing to have a 'do you want to do this important thing or not?' dialogue hidden behind a progress bar that is waiting for the user to answer!

That's an interesting idea.  It's unconventional but I like unconventional...

Another idea would be to put the progress bar into
TheWorldMainDockingBar.  In a distinctive green, it should be easily
noticeable to first-time users.   It could be either centered within
the bar, or overlay it for the duration of progress-monitoring
operation.

 - Chris