[prev in list] [next in list] [prev in thread] [next in thread] 

List:       squeak-dev
Subject:    Re: [squeak-dev] ProgressBar bounces from screen centre to cursor pos, dialogues get hidden at the c
From:       tim Rowledge <tim () rowledge ! org>
Date:       2019-06-20 21:01:08
Message-ID: 2758BD79-0D90-45E2-983D-4F1F0DFB4FF7 () rowledge ! org
[Download RAW message or body]



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


[prev in list] [next in list] [prev in thread] [next in thread]