>> > It seems to do a very nice
>> > job of flashing the morph, and it plays nicely with the "Reuse Windows" preference.
>> > What's not to like?
>>
>> Please see this note from Bob Arning which succinctly describes what's
>> not to like about the original:
>>
>>    http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-August/172823.html
>
> Bob's proposal was discussed at some length, but it was never added to trunk and
> it does not appear in the version history. I think that Karl's submission is
> based on the same idea, except that does it with a "double flash". Is that right?

I think so.

>> > The cmm 8/22/2013 version does not flash nicely, and the kfr 7/3/2014 version
>> > uses delays, which may be problematic. The sw 10/10/1999 version works well and
>> > does not have either problem. How about just using the one the works?
>> >>
>> >> #flashStyle or #flashIntensity preference would be one way to address those
>> >> differences.
>> >
>> > We have enough obscure preferences that have entered the system for reasons
>> > that nobody can even remember. Let's not add another.
>>
>> So, no more preferences at all then?  Ever?  Look, I know what you're
>> trying to say about Preferences, and I think many of them could be
>> removed, but its clear that we all have different interpretations
>> about what #flash is supposed to be for; a low-level notifier or a
>> high-level notifier that can integrate into application-UI's without
>> blocking the UI.
>
> I am saying that preferences should not be added without good reason. Our
> not being able to make up our collective mind about how a morph flash should
> work falls solidly into the "no good reason" category.

Not being able to make up our collective mind is precisely WHEN we
need a preference.  A "preference", by definition, is something that
can vary according to one's individual, umm.. preference.  :)  It's
when we CAN make up our collective mind that we _don't_ need a
preference.

In this instance, not only is there a difference of opinion about the
implementation (whether it is okay to block the UI or not), but we
seem to also be exploring aesthetic differences related to color
(black/white vs. color-negative) and style (double or single flash).
Things related to color and style do fall solidly into the "good
reason for a preference" camp.

You may have simply meant that we should agree whether we need a
preference at all or not.  I agree!  We typically use preferences as a
tool to reconcile, not expand, our differences.  But if no one cares
intensely enough about #flash, we will by definition not need a new
preference.

So I see our options as:

  1) Nothing.  Stick with the non-blocking flash we have.  Not worth
one more line of code.
  2) Add #flash: arg, that switches one or more flash options.  #flash
to call #flash: with users preferred arg.
  3) Non-UI-blocking implementation (Alarms-based, whatever) for a
single 50-100 ms flash and visible with any color morph, even black.

I support any and all of those options.