[squeak-dev] Morph flash (was The Inbox: Morphic-cmm.728.mcz)

Chris Muller asqueaker at gmail.com
Tue Jul 1 01:58:35 UTC 2014

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

> 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

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

More information about the Squeak-dev mailing list