There are a couple of things missing in the progress refactoring I started with sean
- Job/ProgressBar should only use a single progress variable (0.0 - 1.0), no more unbounded min/max/current which leads to duplicate size calculations everywhere - The Visual part should be adapted to only take a single variable into account - The ProgressMorph only updates maximally every 50ms no matter how many change/updates it got - Make sure that concurrent progress are supported (currently only the last added progress morph is updated) On 2012-11-03, at 22:48, Stéphane Ducasse <stephane.duca...@inria.fr> wrote: > Ouch two problems! > > I'm also wondering why we have > > SystemProgressItemMorph and ProgressBarMorph > in addition to SystemProgressMorph > > and of course JobProgressMorph and JobProgressBarMorph > > to me it looks like this is ok to have > > - one with the forbidden flag = JobProgressMorph > - a default one = SystemProgressMorph > and the bar = ProgressBarMorph definitely the hierarchy is mess there. And there are indeed only 4 items needed - the Global displayed SystemProgressMorph which contains multiple progress indicators and the logics to force update the UI even when stuff runs in the UI thread - the item (title + progress bar) - the progress bar - the job item (title + progress bar + interrupt button) > and I saw that the size of the SystemProgressMorph is not passed to the its > inner elements leading to this ugly bar getting out of the > size of the progress bar. the size should and has to be adapted automatically. Currently it's not properly updated since I removed a forced refresh, which makes it >factor 10 faster. Of course this should be rewritten once the previous points have been fixed. My idea was that the progress bar only grows but newer shrinks so that you avoid this nasty size flickering when lots of subjobs are launched. > Stef > > > On Nov 3, 2012, at 10:12 PM, Ciprian Teodorov wrote: > >> Hi Stef, >> >> I have seen this problem too, and I think that JobTest is guilty for this >> behaviour, since its tearDown method removes all bars, even though they are >> not his to remove. >> Try removing the tearDown... it work in my case >> >> JobTest>>tearDown >> SystemProgressMorph uniqueInstance bars do: [ :e | e close ]. >> >> I hope that this helps... >> >> If not I think that there is a problem with the SystemProgressMorph api in a >> concurrent context... An arbitrary class should not be able to remove bars >> from our nice progress morph... >> >> Cheers, >> Ciprian >> >> On Sat, Nov 3, 2012 at 9:57 PM, Stéphane Ducasse <stephane.duca...@inria.fr> >> wrote: >> Yes apparently the code run by the test uses the progress bar (do display >> progress) and at some point put its max to 1 (since there is only one >> definition to process) >> => boum. >> >> since in that case we get a zeroDivide. >> >> Stef >> >> On Nov 3, 2012, at 9:51 PM, Stéphane Ducasse wrote: >> >>> I'm wondering if the progress bar code is not bogus and that it is created >>> with wrong values. >>> >>>> Apparently there was failing test which invoked a on:fork:…. >>>> >>>> This is strange since the processTest were red. >>>> Now running them alone brings green tests. >>>> >>>> <Screen Shot 2012-11-03 at 7.42.47 PM.pdf> >>>> Stef >>>> On Nov 3, 2012, at 12:53 PM, Stéphane Ducasse wrote: >>>> >>>>> There is a bug blocking the image. >>>>> SubscriptOutOfBounds: 0 >>>>> >>>>> in the SystemProgressMorph class updateJob: >>>>> >>>> >>> >>> >> >> >> >> >> >> -- >> Dr. Ciprian TEODOROV >> Ingénieur Développement CAO >> >> tél : 06 08 54 73 48 >> mail : ciprian.teodo...@gmail.com >> www.teodorov.ro > >
