It's all done folks.  Bert, we no longer access the #screen.  Eliot,
the methods and Exception have been moved to ToolBuilder-Kernel.
Frank, it now inherits from Notification.

Thanks all for your feedback.

On Wed, Jun 15, 2011 at 3:34 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
> On Wed, Jun 15, 2011 at 1:30 PM, Levente Uzonyi <leves at elte.hu> wrote:
>>
>> On Wed, 15 Jun 2011, Eliot Miranda wrote:
>>
>>> On Wed, Jun 15, 2011 at 11:20 AM, Chris Muller <asqueaker at gmail.com>
>>> wrote:
>>>
>>>>> This sounds even worse.  Are you implying that you're going to pepper
>>>>> the
>>>>> system with "ProgressInitiationException signal"s just in case there's
>>>>> a
>>>>> progress morph waiting to update?
>>>>
>>>> ProgressInitiationException was put into Squeak (presumably, in the
>>>> Exceptions package) back in 2000 - before I ever started using Squeak.
>>>>  The main entry point for its creation all these years has been
>>>> through String>>#displayProgressAt:from:to:during: - which includes a
>>>> comment with an example, and for which there are senders are all
>>>> throughout the system.  I am not going to pepper anything except my
>>>> English breakfast.  :)
>>>>
>>>
>>> So if that remains the main entry-point (and I think it's poor; one on
>>> UIManager would be better) the exception belongs in Collections, along
>>> side
>>> String.  Btu since progress is a UI function, there needs to be an
>>> entry-point there, and personally I think that either ToolBuilder or a
>>> generic UI package would be the place for both the entry-points such
>>> as #displayProgressAt:from:to:during:, and for the exception.  Just
>>> because
>>> something's been the way its been for 1 years doesn't mean it's right ;)
>>
>> Right, UIManager seems to be a good place. The only value I see in using
>> an exception is that it can be caught, so code can avoid showing the
>> progress, but that feature seems to be rarely used and it can be solved in
>> another way with UIManager.
>>
>>>
>>>
>>>
>>>>> That's absurd, a) on performance grounds,
>>>>> an unhandled exception is an expensive thing (an entire stack walk to
>>>>> discover there's no handler),
>>>>
>>>> There's only one signal which occurs only for the _initiation_, not
>>>> every update.  The exception is instantiated with a workBlock, which
>>>> takes one argument which is the bar that the client-code can then
>>>> update (via #value:).  An unhandled exception may be expensive (still
>>>> usually well under 1 second though, right?), but it's just one signal
>>>> for something that the domain thinks is going to take long enough
>>>> anyway to consider needing to initiate a progress bar..
>>>>
>>>
>>> If the signal is only raised in the context of a progress-epcific
>>> entry-point then that's fine.  Form your initial response to my question
>>> it
>>> seemed that you were talking about something much less contained. An
>>> unhandled exception is likely to cost significantly less than opening a
>>> progress widget, so the cost is acceptable.
>>>
>>>
>>> And I agree with Frank that the progress exception should inherit from
>>> Notification.
>>
>> The word Notification (along with Warning and Error) sounds like a system
>> event. It's nothing more than an Exception with the #defaultAction
>> implemented as ^nil. I wonder what it's original purpose was besides marking
>> Exceptions which implement #defaultAction.
>
> The distinction is between an exception which if uncaught stops execution
> (an exception) and one which if uncaught has no effect (a notification).  So
> ProgressInitiationException is definitely a Notification (IMO :) ).
> best,
> Eliot
>>
>>
>> Levente
>>
>>>
>>> cheers,
>>> Eliot
>>>
>>>>
>>>>  - Chris
>>>>
>>>>
>>>> On Wed, Jun 15, 2011 at 12:07 PM, Eliot Miranda
>>>> <eliot.miranda at gmail.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> On Wed, Jun 15, 2011 at 9:54 AM, Chris Muller <asqueaker at gmail.com>
>>>>
>>>> wrote:
>>>>>>
>>>>>> If, by "the progress bar" you mean SystemProgressMorph, I disagree,
>>>>>> since that would create a dependency on Morphic.
>>>>>> ProgressInitiationException allows domain-level code to signal that
>>>>>> something worth indicating progress is occurring, and different UI
>>>>>> frameworks can capture that notification (or not) and render it each
>>>>>> in their own way.
>>>>>
>>>> b) on neatness/complexity grounds, littering
>>>>>
>>>>> the system with dependencies, yuck.  The Exceptions package is for the
>>>>> exceptions machinery and core exceptions, /not/ for every conceivable
>>>>> exception, notification or warning imaginable.  I haven't been keeping
>>>>
>>>> up,
>>>>>
>>>>> so could you outline the usage model here and give some examples?  I
>>>>
>>>> think
>>>>>
>>>>> there needs to be very careful thought on the interface between domain
>>>>
>>>> code
>>>>>
>>>>> and progress; a) where separation can't be obtained something analogous
>>>>
>>>> to
>>>>>
>>>>> MVC where changed messages are cheap if a Model has no dependents, b)
>>>>
>>>> where
>>>>>
>>>>> separation can be obtained (the traditional showProgessWhile: aBlock
>>>>
>>>> form)
>>>>>
>>>>> the progress additions are nicely encapsulated within the
>>>>
>>>> showProgressWhile:
>>>>>
>>>>> form.
>>>>> best
>>>>> Eliot
>>>>>>
>>>>>>  - Chris
>>>>>>
>>>>>>
>>>>>> On Wed, Jun 15, 2011 at 11:48 AM, Eliot Miranda <
>>>>
>>>> eliot.miranda at gmail.com>
>>>>>>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Chris,
>>>>>>>    just because ProgressInitiationException is an exception doesn't
>>>>>>> imply
>>>>>>> it belongs in exceptions.  Surely it belongs in the same package as
>>>>
>>>> the
>>>>>>>
>>>>>>> progress bar.
>>>>>>> best
>>>>>>> Eliot
>>>>>>>
>>>>>>> On Wed, Jun 15, 2011 at 9:13 AM, <commits at source.squeak.org> wrote:
>>>>>>>>
>>>>>>>> Chris Muller uploaded a new version of Exceptions to project The
>>>>
>>>> Trunk:
>>>>>>>>
>>>>>>>> http://source.squeak.org/trunk/Exceptions-cmm.34.mcz
>>>>>>>>
>>>>>>>> ==================== Summary ====================
>>>>>>>>
>>>>>>>> Name: Exceptions-cmm.34
>>>>>>>> Author: cmm
>>>>>>>> Time: 15 June 2011, 11:13:51.392 am
>>>>>>>> UUID: f0144460-f227-7b43-bee2-019786f35a4e
>>>>>>>> Ancestors: Exceptions-nice.33
>>>>>>>>
>>>>>>>> First step toward preferredProgressBarPosition preference.
>>>>>>>>
>>>>>>>> =============== Diff against Exceptions-nice.33 ===============
>>>>>>>>
>>>>>>>> Item was changed:
>>>>>>>>  Exception subclass: #ProgressInitiationException
>>>>>>>>       instanceVariableNames: 'workBlock maxVal minVal aPoint
>>>>>>>> progressTitle'
>>>>>>>> +       classVariableNames: 'PreferredProgressBarPosition'
>>>>>>>> -       classVariableNames: ''
>>>>>>>>       poolDictionaries: ''
>>>>>>>>       category: 'Exceptions-Kernel'!
>>>>>>>>
>>>>>>>>  !ProgressInitiationException commentStamp: '<historical>' prior: 0!
>>>>>>>>  I provide a way to alter the behavior of the old-style progress
>>>>>>>> notifier
>>>>>>>> in String. See examples in:
>>>>>>>>
>>>>>>>>  ProgressInitiationException testWithout.
>>>>>>>>  ProgressInitiationException testWith.
>>>>>>>>  !
>>>>>>>>
>>>>>>>> Item was changed:
>>>>>>>>  ----- Method: ProgressInitiationException
>>>>>>>> class>>display:at:from:to:during: (in category 'signalling') -----
>>>>>>>> + display: aString at: aPoint from: minVal to: maxVal during:
>>>>
>>>> workBlock
>>>>>>>>
>>>>>>>> - display: aString at: aPoint from: minVal to: maxVal during:
>>>>
>>>> workBlock
>>>>>>>>
>>>>>>>> -
>>>>>>>>       ^ self new
>>>>>>>> +               display: aString
>>>>>>>> +               at: (aPoint ifNil: [ self preferredProgressBarPoint
>>>>
>>>> ])
>>>>>>>>
>>>>>>>> +               from: minVal
>>>>>>>> +               to: maxVal
>>>>>>>> +               during: workBlock!
>>>>>>>> -               display: aString at: aPoint from: minVal to: maxVal
>>>>>>>> during: workBlock!
>>>>>>>>
>>>>>>>> Item was added:
>>>>>>>> + ----- Method: ProgressInitiationException
>>>>>>>> class>>display:from:to:during:
>>>>>>>> (in category 'signalling') -----
>>>>>>>> + display: aString from: minVal to: maxVal during: workBlock
>>>>>>>> +       ^ self
>>>>>>>> +               display: aString
>>>>>>>> +               at: nil
>>>>>>>> +               from: minVal
>>>>>>>> +               to: maxVal
>>>>>>>> +               during: workBlock!
>>>>>>>>
>>>>>>>> Item was added:
>>>>>>>> + ----- Method: ProgressInitiationException
>>>>>>>> class>>preferredProgressBarPoint (in category 'accessing') -----
>>>>>>>> + preferredProgressBarPoint
>>>>>>>> +       ^ self preferredProgressBarPosition = #cursorPoint
>>>>>>>> +               ifTrue: [ Sensor cursorPoint ]
>>>>>>>> +               ifFalse: [ UIManager default screen perform: self
>>>>>>>> preferredProgressBarPosition ]!
>>>>>>>>
>>>>>>>> Item was added:
>>>>>>>> + ----- Method: ProgressInitiationException
>>>>>>>> class>>preferredProgressBarPosition (in category 'accessing') -----
>>>>>>>> + preferredProgressBarPosition
>>>>>>>> +       ^ PreferredProgressBarPosition ifNil: [ #center ]!
>>>>>>>>
>>>>>>>> Item was added:
>>>>>>>> + ----- Method: ProgressInitiationException
>>>>>>>> class>>preferredProgressBarPosition: (in category 'accessing') -----
>>>>>>>> + preferredProgressBarPosition: aSymbol
>>>>>>>> +       "Specify any of:  #center, #topCenter, #bottomCenter,
>>>>>>>> #leftCenter,
>>>>>>>> #rightCenter, #topLeft, #topRight, #bottomLeft or #bottomRight or
>>>>>>>> #cursorPoint."
>>>>>>>> +       ^ PreferredProgressBarPosition!
>>>>>>>>
>>>>>>>> Item was changed:
>>>>>>>>  ----- Method: ProgressInitiationException class>>testInnermost (in
>>>>>>>> category 'examples and tests') -----
>>>>>>>>  testInnermost
>>>>>>>>
>>>>>>>>       "test the progress code WITHOUT special handling"
>>>>>>>>
>>>>>>>>       ^'Now here''s some Real Progress'
>>>>>>>> +               displayProgressFrom: 0
>>>>>>>> -               displayProgressAt: Sensor cursorPoint
>>>>>>>> -               from: 0
>>>>>>>>               to: 10
>>>>>>>>               during: [ :bar |
>>>>>>>>                       1 to: 10 do: [ :x |
>>>>>>>>                               bar value: x. (Delay forMilliseconds:
>>>>>>>> 500)
>>>>>>>> wait.
>>>>>>>>                               x = 5 ifTrue: [1/0].    "just to make
>>>>>>>> life
>>>>>>>> interesting"
>>>>>>>>                       ].
>>>>>>>>                       'done'
>>>>>>>>               ].
>>>>>>>>
>>>>>>>>  !
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>
>
>
>