I will try to reduce the flickering first On Dec 13, 2011, at 1:24 PM, Henrik Sperre Johansen wrote:
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