Progress bar

> Hi
>
> I was looking how we could improve the situation of the progress bar.
> We could "simply" remove some annoying updates (I did some first analysis because I got tired of this).
> I will try to continue so that we have less updates all the times.
>
> Now what I see is that there is also an architectural problem.
> I will try to explain it: each method in different classes (change set, MCloader, FileStream), can be used in
> different scenarios and depending on the path you want or not to raise feedback.
> A bad solution would be to duplicate the method and pass a boolean to indicate whether the feedback should be
> raised or not.
>
> Now I have the impression that the architecture should be:
> - the different part raised events (but this is not clear how)
> - the top level (the part launching) can absorb and aggregate event to give feedback.
> I do not know if it makes sense. Do you know how this is done in other systems.
>
> Stef

> On 13.12.2011 11:01, Stéphane Ducasse wrote:
>> Hi
>>
>> I was looking how we could improve the situation of the progress bar.
>> We could "simply" remove some annoying updates (I did some first analysis because I got tired of this).
>> I will try to continue so that we have less updates all the times.
>>
>> Now what I see is that there is also an architectural problem.
>> I will try to explain it: each method in different classes (change set, MCloader, FileStream), can be used in
>> different scenarios and depending on the path you want or not to raise feedback.
>> A bad solution would be to duplicate the method and pass a boolean to indicate whether the feedback should be
>> raised or not.
>>
>> Now I have the impression that the architecture should be:
>> - the different part raised events (but this is not clear how)
>> - the top level (the part launching) can absorb and aggregate event to give feedback.
>> I do not know if it makes sense. Do you know how this is done in other systems.
>>
>> Stef
> Makes sense to me.
> My suggestion:
> Replace with Announcing progress has been made. (e.g. StartedActivity, ProgressedActivity, EndedActivity )
> The places you want visual feedback (ie when invoked from a GUI), install an listener to the announcements (A ProgressMorph?) which displays the progress bar(s).

> On Dec 13, 2011, at 11:44 AM, Henrik Sperre Johansen wrote:
>
>> On 13.12.2011 11:01, Stéphane Ducasse wrote:
>>> Hi
>>>
>>> I was looking how we could improve the situation of the progress bar.
>>> We could "simply" remove some annoying updates (I did some first analysis because I got tired of this).
>>> I will try to continue so that we have less updates all the times.
>>>
>>> Now what I see is that there is also an architectural problem.
>>> I will try to explain it: each method in different classes (change set, MCloader, FileStream), can be used in
>>> different scenarios and depending on the path you want or not to raise feedback.
>>> A bad solution would be to duplicate the method and pass a boolean to indicate whether the feedback should be
>>> raised or not.
>>>
>>> Now I have the impression that the architecture should be:
>>> - the different part raised events (but this is not clear how)
>>> - the top level (the part launching) can absorb and aggregate event to give feedback.
>>> I do not know if it makes sense. Do you know how this is done in other systems.
>>>
>>> Stef
>> Makes sense to me.
>> My suggestion:
>> Replace with Announcing progress has been made. (e.g. StartedActivity, ProgressedActivity, EndedActivity )
>> The places you want visual feedback (ie when invoked from a GUI), install an listener to the announcements (A ProgressMorph?) which displays the progress bar(s).
> There is already an exception/warning starting and progress.
> I will digest that and see. First reducing the flickering.

> On 13.12.2011 13:00, Stéphane Ducasse wrote:
>> On Dec 13, 2011, at 11:44 AM, Henrik Sperre Johansen wrote:
>>
>>> On 13.12.2011 11:01, Stéphane Ducasse wrote:
>>>> Hi
>>>>
>>>> I was looking how we could improve the situation of the progress bar.
>>>> We could "simply" remove some annoying updates (I did some first analysis because I got tired of this).
>>>> I will try to continue so that we have less updates all the times.
>>>>
>>>> Now what I see is that there is also an architectural problem.
>>>> I will try to explain it: each method in different classes (change set, MCloader, FileStream), can be used in
>>>> different scenarios and depending on the path you want or not to raise feedback.
>>>> A bad solution would be to duplicate the method and pass a boolean to indicate whether the feedback should be
>>>> raised or not.
>>>>
>>>> Now I have the impression that the architecture should be:
>>>> - the different part raised events (but this is not clear how)
>>>> - the top level (the part launching) can absorb and aggregate event to give feedback.
>>>> I do not know if it makes sense. Do you know how this is done in other systems.
>>>>
>>>> Stef
>>> Makes sense to me.
>>> My suggestion:
>>> Replace with Announcing progress has been made. (e.g. StartedActivity, ProgressedActivity, EndedActivity )
>>> The places you want visual feedback (ie when invoked from a GUI), install an listener to the announcements (A ProgressMorph?) which displays the progress bar(s).
>> There is already an exception/warning starting and progress.
>> I will digest that and see. First reducing the flickering.
> Yes, like you said, Exceptions...
> It's one of the things worth changing, imho :)
> To keep it backwards-compatible, one could alias those names to those of Announcements, and keep a backwards-compatible protocol for messages which are found non-suitable (or, use the same).
> My personal main dislike though is the use of displayProgress* protocol rather than the equivalent of announceProgress* or some such, which could then acted upon instead of being displayed directly.
>
> Invoked headlessly/from non-GUI code? Just disregard.
> Invoked headlessly from command-line? Use a listener writing to stdout.
> Invoked from GUI? Use a listener displaying a ProgressMorph.
>
> You can separate headless/GUI with custom UIManagers atm, but the other cases are tricky unless you want your code to meddle about installing custom UIManagers.
>
> Cheers,
> Henry
>