[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.
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.
Schwab,Wilhelm K wrote
Exceptions should be reserved for things that are exceptional :)
Yes :) Although, with humans, progress is an exceptional condition ;-) Also, it'd be *great* if this fix is reviewed quickly because it touches quite a few packages and will rot quickly - S -- View this message in context: http://forum.world.st/New-System-Progress-Bar-tp4635912p4635960.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Thanks sean! Thanks thanks! I never the too smart aspect of the value: And I already removed broken code that performed animation inside :) Looking at your changes now. Stef On Jun 21, 2012, at 4:14 PM, Sean P. DeNigris wrote:
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.
btw, about human readable.., i don't understand, why we don't have something as simple as: collection do: [... ] showingProgress: 'Processing collection' (1 to: 100) do: [ ...] showingProgress: 'Processing ' 1 to: 100 do: [ ...] showingProgress: 'Processing ' i don't care what happens inside, but this interface is IMO much simpler and straightforward: a user just adds showingProgress: at the end, and voila, his silent block now showing a progress. -- Best regards, Igor Stasenko.
What about a Progressing Trait? 2012/6/22 Igor Stasenko <siguctua@gmail.com>
btw, about human readable.., i don't understand, why we don't have something as simple as:
collection do: [... ] showingProgress: 'Processing collection' (1 to: 100) do: [ ...] showingProgress: 'Processing '
1 to: 100 do: [ ...] showingProgress: 'Processing '
i don't care what happens inside, but this interface is IMO much simpler and straightforward: a user just adds showingProgress: at the end, and voila, his silent block now showing a progress.
-- Best regards, Igor Stasenko.
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be| Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
You already have that igor (not as complete as you want, but it's there) Collection >> #do:displayingProgress: On 2012-06-22, at 02:37, Igor Stasenko wrote:
btw, about human readable.., i don't understand, why we don't have something as simple as:
collection do: [... ] showingProgress: 'Processing collection' (1 to: 100) do: [ ...] showingProgress: 'Processing '
1 to: 100 do: [ ...] showingProgress: 'Processing '
i don't care what happens inside, but this interface is IMO much simpler and straightforward: a user just adds showingProgress: at the end, and voila, his silent block now showing a progress.
-- Best regards, Igor Stasenko.
On 22 June 2012 09:46, Camillo Bruni <camillobruni@gmail.com> wrote:
You already have that igor (not as complete as you want, but it's there)
Collection >> #do:displayingProgress:
ah, good to know
On 2012-06-22, at 02:37, Igor Stasenko wrote:
btw, about human readable.., i don't understand, why we don't have something as simple as:
collection do: [... ] showingProgress: 'Processing collection' (1 to: 100) do: [ ...] showingProgress: 'Processing '
1 to: 100 do: [ ...] showingProgress: 'Processing '
i don't care what happens inside, but this interface is IMO much simpler and straightforward: a user just adds showingProgress: at the end, and voila, his silent block now showing a progress.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
It seems that the new progress bar doesn't work well with DummyUIManager, see https://ci.lille.inria.fr/pharo/view/Pharo-Kernel%202.0/job/Pharo%20Kernel%2... -- Pavel On Thu, Jun 21, 2012 at 4:14 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
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.
http://code.google.com/p/pharo/issues/detail?id=6123 On Fri, Jun 22, 2012 at 11:27 AM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
It seems that the new progress bar doesn't work well with DummyUIManager, see https://ci.lille.inria.fr/pharo/view/Pharo-Kernel%202.0/job/Pharo%20Kernel%2...
-- Pavel
On Thu, Jun 21, 2012 at 4:14 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
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.
Pavel Krivanek-3 wrote
The fix is good. Made a slice and marked it FixToInclude... Pavel, I understand we probably don't want progress in the kernel, but can you live with it for a bit while we figure out what to do about progress? There is a lot of discussion on the dev list... Otherwise, I could put the Dummy in it's own package or whatever you suggest. Really, all it's doing is ignoring all messages via DNU, so it could be any object that does that... This was just a patch so Jenkins would start working again while we discuss and clean and enhance... HTH, Sean -- View this message in context: http://forum.world.st/New-System-Progress-Bar-tp4635912p4636154.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
22. 6. 2012 v 15:44, "Sean P. DeNigris" <sean@clipperadams.com>:
Pavel Krivanek-3 wrote
The fix is good. Made a slice and marked it FixToInclude...
Pavel, I understand we probably don't want progress in the kernel, but can you live with it for a bit while we figure out what to do about progress? There is a lot of discussion on the dev list... Otherwise, I could put the Dummy in it's own package or whatever you suggest. Really, all it's doing is ignoring all messages via DNU, so it could be any object that does that... This was just a patch so Jenkins would start working again while we discuss and clean and enhance...
HTH, Sean
I already included the fix into the build scripts so the Jenkins job is working again and we can put other temporary fixes there too. Simply have the alternative UI managers in mind while progress bar redesign :-) I think that classes like that should be in the same package as DummyUIManager. However ignoring of messages by DNU doesn't look as good design to me :-) -- Pavel
-- View this message in context: http://forum.world.st/New-System-Progress-Bar-tp4635912p4636154.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Pavel Krivanek-3 wrote
I already included the fix into the build scripts so the Jenkins job is working again and we can put other temporary fixes there too.
Okay, great! Will these be included if users update though the world menu? Pavel Krivanek-3 wrote
Simply have the alternative UI managers in mind while progress bar redesign :-)
Trust me, I definitely do now, lol! Pavel Krivanek-3 wrote
I think that classes like that should be in the same package as DummyUIManager.
Sounds good to me... Pavel Krivanek-3 wrote
However ignoring of messages by DNU doesn't look as good design to me :-)
Absolutely, it's total rubbish! But (from the vision)... "One step at a time. Perfection can kill movement. Quality is a emerging property." -- View this message in context: http://forum.world.st/New-System-Progress-Bar-tp4635912p4636197.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
participants (7)
-
Camillo Bruni -
Igor Stasenko -
Pavel Krivanek -
phil＠highoctane.be -
Schwab,Wilhelm K -
Sean P. DeNigris -
Stéphane Ducasse