Hi, I spent a little time toward getting our progress-bar back to a
consistent position - as determined by a new preference in
ProgressInitiationException.  Please let me know if you have any
comments on the new Exceptions package.  I don't think any new package
dependencies were created as a result of this - thanks Levente.

We do still have a lot of senders of #displayProgressAt: Sensor
cursorPoint from:to:...  We should simplify those to allow the new
preference to be honored.  However, rather than go through all of them
and create a bunch of new package versions just for that change, how
about we just update them as-we-go; the next time you commit a change
to a package, please browse senders of
String>>#displayProgressAt:from:to:during:, please remove the first
argument (to send String>>#displayProgressFrom:to:during: instead).

These packages are now taken care of:

Toolbuilder-Kernel
Graphics
Exceptions

because they are the ones I just committed.  As other packages are
changed, it would be nice if we could make this update..

Thanks,
  Chris


On Sun, Jun 12, 2011 at 1:55 PM, Chris Muller <ma.chris.m at gmail.com> wrote:
> Sorry for the delayed reply.  Yes absolutely,
> ProgressInitiationException is a better candidate to be responsible
> for knowing the users preferred location for progress-indication than
> DisplayScreen.
>
> I also like the idea of a helper-method that would be able to simplify
> the API; e.g., by not requesting an exact Point location for progress
> bar (by just excluding that argument) and, in that case, falling back
> to the preference.
>
> Requesting an exact point seems like unnecessary flexibility, but
> since it's already supported by the Morphs we may as well leave it.
> However, being able to simplify all of those hundred+ senders (however
> many it is) to not have to repeatedly say, "Display
> preferredProgressPosition" or whatever is addition-by-subtraction.
> Excellent!
>
>  - Chris
>
>
> On Thu, Jun 9, 2011 at 4:31 PM, Levente Uzonyi <leves at elte.hu> wrote:
>> On Tue, 7 Jun 2011, Chris Muller wrote:
>>
>>>> Which class will implement the preference? DisplayScreen?
>>>
>>> Yes, that seems like a very reasonable candidate to me.  My only
>>> question is, do we want to maintain #cursorPoint as a viable option
>>> for displaying progress bar?  It seems reasonable to me, but then we
>>> would have to either have a case check or implement cursorPoint on
>>> DisplayScreen..
>>>
>>
>> Thinking a bit about it I came to the following idea:
>> The preference would be added to ProgressInitiationException. The values of
>> the preference would be symbols, like #cursorPoint, #center, #topCenter,
>> etc. The exception would use UIManager to find out what the symbol means.
>> The value of the preference would be used when no point would be requested
>> (nil value). This way we wouldn't introduce unnecessary dependencies.
>> Ideally one would be able to write things like
>> 'foo' displayProgressAt: #center from: ...
>> Or another helper method using the value of the preference:
>> 'foo' displayProgressFrom: ...
>>
>> This requires a new kind of preference where the user can select it's value
>> from a predefined list. I'm sure this would also be useful in other cases.
>>
>> What do you think?
>>
>>
>> Levente
>>
>
>