ProgressBar bounces from screen centre to cursor pos, dialogues get hidden at the centre
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@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Quo signo nata es? = What's your sign?
On Wed, Jun 19, 2019, 17:43 tim Rowledge tim@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@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Quo signo nata es? = What's your sign?
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
On 2019-06-20, at 10:40 AM, Chris Muller asqueaker@gmail.com 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; tim@rowledge.org; http://www.rowledge.org/tim Two wrongs are only the beginning.
Hi all!
Did this bouncing effect disappear after my recent changes to Morphic layout?
Best, Marcel Am 20.06.2019 23:14:09 schrieb tim Rowledge tim@rowledge.org:
On 2019-06-20, at 10:40 AM, Chris Muller 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; tim@rowledge.org; http://www.rowledge.org/tim Two wrongs are only the beginning.
Hi,
I just experienced another issue with ProgressBars:
[cid:05b41a7c-55c2-483f-8707-74c4c79fae07]
Looks more than a missing "Display reset" than an actual layout problem.
If I can reproduce it, I will reply again.
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Montag, 2. September 2019 11:52:11 An: gettimothy via Squeak-dev; Chris Muller Betreff: Re: [squeak-dev] ProgressBar bounces from screen centre to cursor pos, dialogues get hidden at the centre
Hi all!
Did this bouncing effect disappear after my recent changes to Morphic layout?
Best, Marcel
Am 20.06.2019 23:14:09 schrieb tim Rowledge tim@rowledge.org:
On 2019-06-20, at 10:40 AM, Chris Muller 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; tim@rowledge.org; http://www.rowledge.org/tim Two wrongs are only the beginning.
Hi Christoph,
I think that the amount of progress bars is also an issue. The bouncing thing was actual bouncing between cursor position and world center.
Best, Marcel Am 15.09.2019 19:20:53 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi,
I just experienced another issue with ProgressBars:
Looks more than a missing "Display reset" than an actual layout problem.
If I can reproduce it, I will reply again.
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Montag, 2. September 2019 11:52:11 An: gettimothy via Squeak-dev; Chris Muller Betreff: Re: [squeak-dev] ProgressBar bounces from screen centre to cursor pos, dialogues get hidden at the centre Hi all!
Did this bouncing effect disappear after my recent changes to Morphic layout?
Best, Marcel Am 20.06.2019 23:14:09 schrieb tim Rowledge tim@rowledge.org:
On 2019-06-20, at 10:40 AM, Chris Muller 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; tim@rowledge.org; http://www.rowledge.org/tim Two wrongs are only the beginning.
I think the two parts of the problem are a) the progress bar probably shouldn't pay attention to the requested location if it is already open; that would stop the bouncing around b) we need to be less lazy about "oh, I guess I'll just open this in the center of the Display", especially when combined with "be at the top of the stack".
One option to help solve b) might be to add any dialogues that get popped up whilst there is an open progress bar to the progress bar just as secondary progress bars ... err, getting lost here... do/does/go.Adding them to the top would probably be most effective since they tend to be something that needs immediate attention before the progress can continue.
Another possibility might be to try to be more aware of layers and locations of things on-screen. We have (or at least had) a RealEstateManager to help with placing freshly opened windows. Could that (or something similar) help with placing UI items like dialogues when there are multiple items to display?
A related issue is making sure any menus that get popped up are made visible; that might be simpler since surely the major fact about a menu being pooped up is that it should be absolutely at the top of the stack?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim If it was easy, the hardware people would take care of it.
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@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@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Quo signo nata es? = What's your sign?
On 2019-06-20, at 11:42 AM, karl ramberg karlramberg@gmail.com 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; tim@rowledge.org; http://www.rowledge.org/tim Madness takes its toll - please have exact change ready
squeak-dev@lists.squeakfoundation.org
-
Chris Cunningham -
Chris Muller -
karl ramberg -
Marcel Taeumel -
Thiede, Christoph -
tim Rowledge