On Mon, Jun 30, 2014 at 4:04 PM, Bert Freudenberg <bert@freudenbergs.de> wrote:

On 30.06.2014, at 21:54, tim Rowledge <tim@rowledge.org> wrote:

>
> On 30-06-2014, at 12:52 PM, Chris Muller <asqueaker@gmail.com> wrote:
>
>>
>> We probably need to decide whether we want #flash to be a debugging tool or something any morph should be able to do in a way that properly integrates with the Morphic framework...
>>
>> It seems we want it fairly often-enough as a IDE tool, I wouldn't be opposed to a small delay...
>>
>>
> Seems pretty obvious to me - add a #slowFlashAlert method and leave the plain flash alone.
>
> tim

UserDialogBoxMorph has a special flash method that is nicely visible. Try this and click outside:

self confirm: 'foo'

For a general (non-modal) version it would be nicer to use alarms instead of delays, but I like the "double blink" effect.

I think a separate method like #slowFlash may not satisfy those who are objecting to UI-blockage. For them, it's not about #flash blocking or not, it's about the entire UI ever blocking, or not. If we introduce UI-blocking methods in and start calling them from the Tools, that may be denying them their objection.

An alarms-based solution was proposed, but there was resistance to its complexity.

It seems like we want to support a variety of flash types, maybe simply let each image configure its own preferred #flashIntensity? Like, #nonBlocking, #singleFrame, #doubleBlink, and #swizzleZoom.

Consumption of the preference would be from just one method, #flash, so, a simple implementation.