ProgressBar bounces from screen centre to cursor pos, dialogues get hidden at the centre

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

ProgressBar bounces from screen centre to cursor pos, dialogues get hidden at the centre

timrowledge
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; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Quo signo nata es? = What's your sign?



cbc
Reply | Threaded
Open this post in threaded view
|

Re: ProgressBar bounces from screen centre to cursor pos, dialogues get hidden at the centre

cbc


On Wed, Jun 19, 2019, 17:43 tim Rowledge <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Quo signo nata es? = What's your sign?





Reply | Threaded
Open this post in threaded view
|

Re: ProgressBar bounces from screen centre to cursor pos, dialogues get hidden at the centre

Chris Muller-3
In reply to this post by timrowledge
> 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

Reply | Threaded
Open this post in threaded view
|

Re: ProgressBar bounces from screen centre to cursor pos, dialogues get hidden at the centre

Karl Ramberg
In reply to this post by timrowledge
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 <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Quo signo nata es? = What's your sign?





Reply | Threaded
Open this post in threaded view
|

Re: ProgressBar bounces from screen centre to cursor pos, dialogues get hidden at the centre

timrowledge


> On 2019-06-20, at 11:42 AM, karl ramberg <[hidden email]> wrote:
>
> 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.

My guess there would be that when the World is destroyed (gulp) the answer given for screen centre is 0@0 and the progress bar is moved as near that as possible whilst staying on-screen.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Madness takes its toll - please have exact change ready



Reply | Threaded
Open this post in threaded view
|

Re: ProgressBar bounces from screen centre to cursor pos, dialogues get hidden at the centre

timrowledge
In reply to this post by Chris Muller-3


> On 2019-06-20, at 10:40 AM, Chris Muller <[hidden email]> wrote:
>
>> 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...

Wild guess - make it ignore new positions coming via the route that tries to open a progressbar when one is already open. It ought to be possible to manually drag it around though.

>> [snip] 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

The problem with sticking progress bar there is that we have the stacking of bars as sub-loads start. I don't think that would fit too cleanly into the dock. At least, not the way we do it now; perhaps one could collapse the prior bar into a single char sized icon and add the new bar, then obviously, reverse that as bars finish and return up the stack.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Two wrongs are only the beginning.