<br><br><div class="gmail_quote">On Wed, Jun 15, 2011 at 11:20 AM, Chris Muller <span dir="ltr"><<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> This sounds even worse. Are you implying that you're going to pepper the<br>
> system with "ProgressInitiationException signal"s just in case there's a<br>
> progress morph waiting to update?<br>
<br>
</div>ProgressInitiationException was put into Squeak (presumably, in the<br>
Exceptions package) back in 2000 - before I ever started using Squeak.<br>
The main entry point for its creation all these years has been<br>
through String>>#displayProgressAt:from:to:during: - which includes a<br>
comment with an example, and for which there are senders are all<br>
throughout the system. I am not going to pepper anything except my<br>
English breakfast. :)<br></blockquote><div><br></div><div>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 ;)</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> That's absurd, a) on performance grounds,<br>
> an unhandled exception is an expensive thing (an entire stack walk to<br>
> discover there's no handler),<br>
<br>
</div>There's only one signal which occurs only for the _initiation_, not<br>
every update. The exception is instantiated with a workBlock, which<br>
takes one argument which is the bar that the client-code can then<br>
update (via #value:). An unhandled exception may be expensive (still<br>
usually well under 1 second though, right?), but it's just one signal<br>
for something that the domain thinks is going to take long enough<br>
anyway to consider needing to initiate a progress bar..<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div><br></div><div>And I agree with Frank that the progress exception should inherit from Notification.</div><div><br></div><div>cheers,</div><div>Eliot</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
- Chris<br>
</font><div class="im"><br>
<br>
On Wed, Jun 15, 2011 at 12:07 PM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
><br>
><br>
> On Wed, Jun 15, 2011 at 9:54 AM, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br>
>><br>
>> If, by "the progress bar" you mean SystemProgressMorph, I disagree,<br>
>> since that would create a dependency on Morphic.<br>
>> ProgressInitiationException allows domain-level code to signal that<br>
>> something worth indicating progress is occurring, and different UI<br>
>> frameworks can capture that notification (or not) and render it each<br>
>> in their own way.<br>
><br>
</div><div><div></div><div class="h5">b) on neatness/complexity grounds, littering<br>
> the system with dependencies, yuck. The Exceptions package is for the<br>
> exceptions machinery and core exceptions, /not/ for every conceivable<br>
> exception, notification or warning imaginable. I haven't been keeping up,<br>
> so could you outline the usage model here and give some examples? I think<br>
> there needs to be very careful thought on the interface between domain code<br>
> and progress; a) where separation can't be obtained something analogous to<br>
> MVC where changed messages are cheap if a Model has no dependents, b) where<br>
> separation can be obtained (the traditional showProgessWhile: aBlock form)<br>
> the progress additions are nicely encapsulated within the showProgressWhile:<br>
> form.<br>
> best<br>
> Eliot<br>
>><br>
>> - Chris<br>
>><br>
>><br>
>> On Wed, Jun 15, 2011 at 11:48 AM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>><br>
>> wrote:<br>
>> > Hi Chris,<br>
>> > just because ProgressInitiationException is an exception doesn't<br>
>> > imply<br>
>> > it belongs in exceptions. Surely it belongs in the same package as the<br>
>> > progress bar.<br>
>> > best<br>
>> > Eliot<br>
>> ><br>
>> > On Wed, Jun 15, 2011 at 9:13 AM, <<a href="mailto:commits@source.squeak.org">commits@source.squeak.org</a>> wrote:<br>
>> >><br>
>> >> Chris Muller uploaded a new version of Exceptions to project The Trunk:<br>
>> >> <a href="http://source.squeak.org/trunk/Exceptions-cmm.34.mcz" target="_blank">http://source.squeak.org/trunk/Exceptions-cmm.34.mcz</a><br>
>> >><br>
>> >> ==================== Summary ====================<br>
>> >><br>
>> >> Name: Exceptions-cmm.34<br>
>> >> Author: cmm<br>
>> >> Time: 15 June 2011, 11:13:51.392 am<br>
>> >> UUID: f0144460-f227-7b43-bee2-019786f35a4e<br>
>> >> Ancestors: Exceptions-nice.33<br>
>> >><br>
>> >> First step toward preferredProgressBarPosition preference.<br>
>> >><br>
>> >> =============== Diff against Exceptions-nice.33 ===============<br>
>> >><br>
>> >> Item was changed:<br>
>> >> Exception subclass: #ProgressInitiationException<br>
>> >> instanceVariableNames: 'workBlock maxVal minVal aPoint<br>
>> >> progressTitle'<br>
>> >> + classVariableNames: 'PreferredProgressBarPosition'<br>
>> >> - classVariableNames: ''<br>
>> >> poolDictionaries: ''<br>
>> >> category: 'Exceptions-Kernel'!<br>
>> >><br>
>> >> !ProgressInitiationException commentStamp: '<historical>' prior: 0!<br>
>> >> I provide a way to alter the behavior of the old-style progress<br>
>> >> notifier<br>
>> >> in String. See examples in:<br>
>> >><br>
>> >> ProgressInitiationException testWithout.<br>
>> >> ProgressInitiationException testWith.<br>
>> >> !<br>
>> >><br>
>> >> Item was changed:<br>
>> >> ----- Method: ProgressInitiationException<br>
>> >> class>>display:at:from:to:during: (in category 'signalling') -----<br>
>> >> + display: aString at: aPoint from: minVal to: maxVal during: workBlock<br>
>> >> - display: aString at: aPoint from: minVal to: maxVal during: workBlock<br>
>> >> -<br>
>> >> ^ self new<br>
>> >> + display: aString<br>
>> >> + at: (aPoint ifNil: [ self preferredProgressBarPoint ])<br>
>> >> + from: minVal<br>
>> >> + to: maxVal<br>
>> >> + during: workBlock!<br>
>> >> - display: aString at: aPoint from: minVal to: maxVal<br>
>> >> during: workBlock!<br>
>> >><br>
>> >> Item was added:<br>
>> >> + ----- Method: ProgressInitiationException<br>
>> >> class>>display:from:to:during:<br>
>> >> (in category 'signalling') -----<br>
>> >> + display: aString from: minVal to: maxVal during: workBlock<br>
>> >> + ^ self<br>
>> >> + display: aString<br>
>> >> + at: nil<br>
>> >> + from: minVal<br>
>> >> + to: maxVal<br>
>> >> + during: workBlock!<br>
>> >><br>
>> >> Item was added:<br>
>> >> + ----- Method: ProgressInitiationException<br>
>> >> class>>preferredProgressBarPoint (in category 'accessing') -----<br>
>> >> + preferredProgressBarPoint<br>
>> >> + ^ self preferredProgressBarPosition = #cursorPoint<br>
>> >> + ifTrue: [ Sensor cursorPoint ]<br>
>> >> + ifFalse: [ UIManager default screen perform: self<br>
>> >> preferredProgressBarPosition ]!<br>
>> >><br>
>> >> Item was added:<br>
>> >> + ----- Method: ProgressInitiationException<br>
>> >> class>>preferredProgressBarPosition (in category 'accessing') -----<br>
>> >> + preferredProgressBarPosition<br>
>> >> + ^ PreferredProgressBarPosition ifNil: [ #center ]!<br>
>> >><br>
>> >> Item was added:<br>
>> >> + ----- Method: ProgressInitiationException<br>
>> >> class>>preferredProgressBarPosition: (in category 'accessing') -----<br>
>> >> + preferredProgressBarPosition: aSymbol<br>
>> >> + "Specify any of: #center, #topCenter, #bottomCenter,<br>
>> >> #leftCenter,<br>
>> >> #rightCenter, #topLeft, #topRight, #bottomLeft or #bottomRight or<br>
>> >> #cursorPoint."<br>
>> >> + ^ PreferredProgressBarPosition!<br>
>> >><br>
>> >> Item was changed:<br>
>> >> ----- Method: ProgressInitiationException class>>testInnermost (in<br>
>> >> category 'examples and tests') -----<br>
>> >> testInnermost<br>
>> >><br>
>> >> "test the progress code WITHOUT special handling"<br>
>> >><br>
>> >> ^'Now here''s some Real Progress'<br>
>> >> + displayProgressFrom: 0<br>
>> >> - displayProgressAt: Sensor cursorPoint<br>
>> >> - from: 0<br>
>> >> to: 10<br>
>> >> during: [ :bar |<br>
>> >> 1 to: 10 do: [ :x |<br>
>> >> bar value: x. (Delay forMilliseconds:<br>
>> >> 500)<br>
>> >> wait.<br>
>> >> x = 5 ifTrue: [1/0]. "just to make<br>
>> >> life<br>
>> >> interesting"<br>
>> >> ].<br>
>> >> 'done'<br>
>> >> ].<br>
>> >><br>
>> >> !<br>
>> >><br>
>> >><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>><br>
><br>
><br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br>