Bouncing progress bars and hiding of notifiers

Something annoying and hopefully simple to fix in a way that makes it worth getting into 5.3 is the way progress bars can bounce around the screen. It's visually distracting and somehow a bit tacky. It's not the particular location of the morph (more on that later) but the
bounce
                              of
        the
dratt
                                          ed
           thing.

I *think* that the simplest way to solve this is to prevent a new #requestedPosition: from being noted when the progress bar is already in operation. The obvious way to do this might be to only set the requestedPosition if it is currently nil.
However, having a persistent class var UniqueInstance complicates life a fraction since we can't rely on the requested position being nil when we 'first' open a progress bar. We could probably set it back to nil in SystemProgressMorph>>#freeSlot: when the 'self delete' is run.
For a simplest-possible fix, it looks like checking the activeSlots value is effective; by not changing the requested position if activeSlots > 0 it seems to work.
My example here is
        'Progress'
                displayProgressAt: Display center
                from: 0 to: 10
                during: [:bar | 0 to: 10 do: [:i | bar value: i.
                        'Progress2' displayProgressAt: 200@300
                                from: 0 to: 100
                                during: [:baz | 0 to: 100 do: [:j | baz value: j.
                                        (Delay forMilliseconds: 2) wait]]]].
... where previously the progress bar would leap tall buildings in a single bound. You get the picture.

Proposed fix in inbox Morphic-tpr.1616

A related issue we have discussed on the list before is the unfortunate case where sometihng goes wrong during a large upload and a Notifier/Informer/Confirmer gets hidden behind a progress bar with many active bars. I've seen this during loading large packages like Seaside, for example. The system is stuck waiting for you to do something with the notifier but it is sat behind a large progress bar and nobody has a clue what is happening.

A very simple workaround for this is to slightly offset the default position used when no explicit position is provided for the progress bar. Currently that is #center, as in centre of the screen. I noticed we already have a related solution in Rectangle - #aboveCenter as used in ModalSystemWindowView. So by adding a #belowCenter that aims a bit below the center (duh) we get a progress bar defaulting to just a bit lower on the screen. Obviously this doesn't solve for any cases where the bar is deliberately opened at the screen center.

I'd like to suggest setting the default position for the assorted notifier/confirmer/informer windows using the #aboveCenter but right now as I look at the code for opening assorted UserDialogBoxMorphs I find my brain melting. Some methods accept an argument for the position but ignore it, some test the position for nil and use a preferred position, some use the current Hand position in combination with the center point of a specified submorph... crikey.

I suspect there are better ways to solve the problem. Perhaps making sure the progress bar doesn't end up in front might be simpler? Perhaps catching the inform/confirm request and incorporating it into any active progress bar morph; that seems more complex than we'd want now.

Proposed improvement in inbox ToolBuilder-Kernel-tpr.135

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
BASIC is to computer programming as QWERTY is to typing.

---