[squeak-dev] flash revisited

David T. Lewis lewis at mail.msen.com
Wed Jul 9 02:03:26 UTC 2014

On Tue, Jul 08, 2014 at 08:17:03PM -0500, Chris Muller wrote:
> >> > 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.

No, I really did mean that adding a preference for this would be a horrible
thing to do. It's the internet equivalent of design by committee. The
committee cannot figure out what to do, so it tries to make everybody on
the committee happy. Meanwhile, the customer is left to wonder "why did
these idiots design a camel when I wanted a horse?"

> 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.

I like the option that Eliot proposed:

On Tue, Jul 08, 2014 at 05:38:59AM -0700, Eliot Miranda wrote:
> Perceptually, a flash needs to last something like a 1/10th if a second
> to be easily visible.  Clearly a simple reverse won't work.  Bert has
> explained that using alarms, rather than delays, can implement flash without
> blocking.  Surely we can do the right thing here and implement flash having
> a consistent duration and not blocking?

Assuming that this is in fact the right thing to do, I guess we just need
someone to do it.


More information about the Squeak-dev mailing list