> On 2020-01-06, at 7:52 PM, Chris Muller <
[hidden email]> wrote:
>
> On Mon, Jan 6, 2020 at 5:01 PM tim Rowledge <
[hidden email]> wrote:
> Does anyone object to the suggestions I made for the progress bars? If no, I propose to move them to trunk soon.
>
> Proposed fix in inbox Morphic-tpr.1616
>
> Would it be better to filter the repositioning from SystemProgressMorph>>#reposition, rather than blocking the setting of the domain value?
Perhaps; I looked at that and concluded the other way is a less intrusive change *for now*; I think it can be done better at the cost of more work that we done want to do right now.
>
> Proposed improvement in inbox ToolBuilder-Kernel-tpr.135
>
> The stated reason for it is: "This should at least help with cases where a notifier/conformer/informer pops up during a large package load and gets hidden behind the progress bar morph."
>
> Why not fix THAT then? I just struggle with the idea of making Squeak's progress bar look weird 100% of the time, by de-centering it, "just in case" a problem happens 1% of the time. Sorry Tim.
More work than I think we should do *right now*, that's all. By pushing the progress bar down a little it gives just enough room for a popup dialogue that is screen-centre to still be visible. That's all; it's the simplest possible thing for right now. As I mentioned a few times, there should be a much better solution - maybe the RealEstate thingy should handle it - or perhaps some clever merging of progress bars and notifiers into a mega-notifier-wotist. But not today. Today a simple change can save frustration when loading large packages that ask for user input in a way that sticks the dialogue behind and under the progress bar morph. If you have a better solution that is simple enough to justify being added today I'd be very happy.
tim
--
tim Rowledge;
[hidden email];
http://www.rowledge.org/timDeath to all fanatics!
Locked
