Thanks
I will try to digest that.
> - 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 <[email protected]> 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
>>> <[email protected]> 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 : [email protected]
>>> www.teodorov.ro
>>
>>
>
>
