Hi,

> I think forcing a double-blink for every possible use-case for #flash won't
> work.  Plus, an arbitrary 50ms delay will not let anyone be happy because
> some want absolutely no blockage while others wanted more than 50ms..
>
> #flashStyle or #flashIntensity preference would be one way to address those
> differences.
>
>
>
> It's a hack.  It complicates without adding anything.  Perceptually, a flash

It's hackish, but as I said before, consumption is from one single
method, so its NOT complicated at all.  What it "adds" is the ability
for each image to treat flash as a low-level or high-level
notification (e.g., blocking or not).

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

Someone already proposed an alarms based solution in the original
thread, but it was disapproved by mulitple parties as "way too much"
(see the thread).  Maybe everyone has changed their minds, which is
fine, but the TSTTCPW approach I'm proposing lets us play and
understand how we want to use #flash until then, WITHOUT a
complicated, irreversible implementation like alarms.  It's totally
reversible, buys us time to think about it in real-world contexts.

Besides that, I'm kind of stunned that you would believe
one-flash-fits-all.  I never needed ANY flash for Reuse Windows, but I
could tolerate a single flash when a window was already open.  A
double flash though?  That could get annoying to see that every time a
window is topped.

So, I think there should be a preference even if we go with the
Alarms-based solution..