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

>
> On 30.06.2014, at 21:54, tim Rowledge <tim at rowledge.org> wrote:
>
> >
> > On 30-06-2014, at 12:52 PM, Chris Muller <asqueaker at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140630/9e073699/attachment.htm