On Wed, Jun 19, 2019, 17:43 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?
>
making the progress bars stay where they are now - a very big +1.
Further, if we manually place the progress somewhere else (say while fixing
issues in a debugger) I'd really like it to stay in that new location as
well.

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!
>

adding dialog to the progress bars - worth a prototype.

another idea might be to tile them like the debugger get tiled now. but
maybe with a different compass positions?

all this said - I am definitely not a UI expert (nor even mildly
knowledgable). but i do know what i don't like, and sometimes what I DO
like.

-cbc

>
> 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/20190619/e572ffbc/attachment.html>