I recall there is some problem with the ProgressBar and other dialogs when
their World becomes nil.
Then they will locate to the top left corner. Same issue happens when
updating the image, dialogs appear in top left corner.

Best,
Karl


On Thu, Jun 20, 2019 at 2:43 AM tim Rowledge <tim at rowledge.org> wrote:

> I've mentioned this in passing before.
>
> 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.
>
> 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?
>
> 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!
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Useful Latin Phrases:- Quo signo nata es? = What's your sign?
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190620/5a840fe2/attachment.html>