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.