Hi I have the impression that it would be good that we have a way to specify that either a UI feedback should be standalone or that it can be standalone if not invoked when another ui feedback tasks place (in such a case it can be part of the previous line.
I was trying to reduce the stack of progressbar we have during the update
Utilities creates one for number of CS. (I removed it in 11306 as an
experiment)
NewChangeSetfromStream create the empty one
Then MC
Then HTTP protocol
So what would be nice is a way to control that without having to know the
context is which a feedback is sent.
Does any of you have an idea: because I'm not satisfied with the removal in the
Utilities for CS
<<inline: Screen shot 2010-04-05 at 10.22.24 AM.png>>
Right now
ProgressNotification signal: '' extra: val makes sure that the feedback
is made as show below with defaultMorphicAction
ProgressInitiationException>>defaultMorphicAction
| result progress |
progress := SystemProgressMorph label: progressTitle min: minVal max:
maxVal.
[[result := workBlock value: progress] on: ProgressNotification do:
[:ex|
ex extraParam isString
ifTrue: [SystemProgressMorph uniqueInstance labelAt:
progress put: ex extraParam].
ex resume]] ensure: [SystemProgressMorph close: progress].
self resume: result
We can use sendNotificaton to change that
ProgressInitiationException>>sendNotificationsTo: aNewBlock
self resume: (
workBlock value: [ :barVal |
aNewBlock value: minVal value: maxVal value: barVal])
But 'Loading....'
displayProgressAt: Sensor cursorPoint
from: 0
to: self size
during:
[:bar |
.....
Create a ProgressInitiationException...
displayProgressAt: aPoint from: minVal to: maxVal during: workBlock
"Display this string as a caption over a progress bar while workBlock
is evaluated.
EXAMPLE (Select next 6 lines and Do It)
'Now here''s some Real Progress'
displayProgressAt: Sensor cursorPoint
from: 0 to: 10
during: [:bar |
1 to: 10 do: [:x | bar value: x.
(Delay forMilliseconds: 500) wait]].
HOW IT WORKS (Try this in any other language :-)
Since your code (the last 2 lines in the above example) is in a block,
this method gets control to display its heading before, and clean up
the screen after, its execution.
The key, though, is that the block is supplied with an argument,
named 'bar' in the example, which will update the bar image every
it is sent the message value: x, where x is in the from:to: range."
^ProgressInitiationException
display: self
at: aPoint
from: minVal
to: maxVal
during: workBlock
So is it me or the design above (which I like) is not smart enough so that we
do not have to consider to change
a display:....during into a ProgressNotification signal: '' extra: val to be
sure that we do not stack progress bar.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
