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.
Cheers, Henry