[squeak-dev] The Inbox: Morphic-kfr.731.mcz

Chris Muller ma.chris.m at gmail.com
Tue Jul 8 16:29:08 UTC 2014


On Mon, Jul 7, 2014 at 10:09 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> On Mon, Jul 07, 2014 at 07:42:28PM -0500, Chris Muller wrote:
>> 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..
>
> OK, I'll bite. What exactly was wrong with the original implementation of
> Morph>>flash dated 10/10/1999 by Scott Wallace?

Dave, could you possibly try this out to find the answer to your question?

  - In a trunk image, add this repository to the Morphic package:

       MCHttpRepository
            location: 'http://box4.squeak.org:8888/trunk'
            user: 'squeak'
            password: 'squeak'

  - Revert Morph>>#flash to the one you're interested in knowing about
-- (cmm 10/6/2012 15:54) which the one that is just after Scott
Wallace's 1999 version.
  - In a Browser or Hierarchy browser, now select that Morph>>#flash,
then right click on it.  Be patient, it might take a second or two for
the menu to appear (to properly determine whether those options should
be enabled in the menu).
  - Select "browse mc origin".  Wait up to 10 seconds (hey, it's a lot
faster than doing it manually!).  The MCVersion inspector appears
documenting all changes that went in along with that change of #flash.

The answer to your question is the 2nd bullet line.

> It seems to do a very nice
> job of flashing the morph, and it plays nicely with the "Reuse Windows" preference.
> What's not to like?

Please see this note from Bob Arning which succinctly describes what's
not to like about the original:

   http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-August/172823.html

> The cmm 8/22/2013 version does not flash nicely, and the kfr 7/3/2014 version
> uses delays, which may be problematic. The sw 10/10/1999 version works well and
> does not have either problem. How about just using the one the works?
>>
>> #flashStyle or #flashIntensity preference would be one way to address those
>> differences.
>>
>
> We have enough obscure preferences that have entered the system for reasons
> that nobody can even remember. Let's not add another.

So, no more preferences at all then?  Ever?  Look, I know what you're
trying to say about Preferences, and I think many of them could be
removed, but its clear that we all have different interpretations
about what #flash is supposed to be for; a low-level notifier or a
high-level notifier that can integrate into application-UI's without
blocking the UI.


More information about the Squeak-dev mailing list