Events are preferable to exceptions for updating the bar. Exceptions should be reserved for things that are exceptional :) Event registrations should be weak so that one *can* set and forget, but one should also be able to explicitly unregister if desired/needed. I will also take this opportunity to re-assert that weak collections should be inherently thread-safe and self-repairing. Pharo's weaklings do not measure up to Dolphin's in these areas. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [sean@clipperadams.com] Sent: Thursday, June 21, 2012 10:14 AM To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] New System Progress Bar To help explain the changes, here's a snippet from the fix to "Issue 6099: Deprecate #value: for system progress (was red cross during updates)" (http://code.google.com/p/pharo/issues/detail?id=6099). The API (see SystemProgressItemMorph) is not set in stone, but it's already much less confusing than the old pseudo-class implementation. Ultimately, I'd like to move to announcements instead of exceptions to signal progress, and decouple the progress model/view - maybe just [un]registering the progress morph to enable/disable. The slice in the inbox for this issue should fix the "red cross during updates" problem... MOTIVATION: The old system progress worked like this (for example)... SystemProgressMorph show: 'Doing...' from: 1 to: 100 during: [ :bar | 1 to: 100 do: [ :x | bar value: x. bar value: 'On iteration ', x asString. (Delay forMilliseconds: 20) wait "Just to slow it down so we can see what's going on" ] ]. * The work block ([ :bar | ... ] above) would accept one argument * That argument (:bar above) would be a block, that would act as a pseudo-class. Depending on what was passed to #value:, it would perform different functions. Two are illustrated above: - #value: aNumber; where aNumber is between the min and max of the progress range -> Set the bar's current progress mark to that position. For example, 'bar value: 50' above would show the operation half complete - #value: aString -> Set the label of the progress morph to aString This was very confusing, so we created a real class, SystemProgressItemMorph, which now gets passed to the work block, and has a real API. So, for example, the following becomes: SystemProgressMorph show: 'Doing...' from: 1 to: 100 during: [ :bar | 1 to: 100 do: [ :x | bar current: x. bar label: 'On iteration ', x asString. (Delay forMilliseconds: 20) wait "Just to slow it down so we can see what's going on" ] ]. As you can see, '#value: newValue' has become '#current: newValue', and '#value: newLabel' has become '#label: newLabel'. One wrinkle is that some users were passing a nil-like block instead of the the pseudo-class to suppress the system progress bar. For example: informUserDuring: aBlock aBlock value: [:string | ]. Above, [:string | ] would now cause a DNU when sent, for example, #current:, which obviously blocks don't understand. So, these cases were changed like so: informUserDuring: aBlock aBlock value: DummySystemProgressItem new. Where DummySystemProgressItem simply ignores all messages without signaling an error -- View this message in context: http://forum.world.st/New-System-Progress-Bar-tp4635912.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.