[squeak-dev] computers too fast these days?

Chris Muller asqueaker at gmail.com
Mon Aug 19 18:53:22 UTC 2013


I agree with Bob.  100ms only "slows the UI" down to 10 fps for one
"frame."  By holding everything else static for that one frame, it
reinforces the purpose of flash which is to draw the users attention
to that one particular morph.

In an extremely busy-animated UI, flash might otherwise not fulfill
this goal as effectively.

Animation in morphic is normally handled by implementing #step and
#stepTime, not alarms.  But #flash is not animation, it's like #beep.
It's a user poke, not program output.


On Mon, Aug 19, 2013 at 1:34 PM, Bob Arning <arning315 at comcast.net> wrote:
> Think about where it's used in the image now. I search for some text and
> it's not found. The screen flashes to let me know. I can't think of
> *anything* I want the UI process to be doing for the next 100ms while I wait
> for the photons to hit my retina. I'm even thinking a bit longer delay might
> even be better. Here are some experiments:
>
> Make a morph.
>
> m _ Morph new openInWorld.
>
> Then try this, with different proposed #flash implementations.
>
> m flash; delete.
>
> Another experiment. How low can you set the delay and still reliably see
> red? Try this in a completely empty project.
>
> m color: Color red.
> World displayWorldSafely.
> (Delay forMilliseconds: 20) wait.
> m color: Color blue.
> World displayWorldSafely.
>
> I think the senders of #flash want it to be seen and I don't think the UI
> needs to do anything else while the message is being received by the user
> (the U in UI).
>
> Cheers,
> Bob
>
> On 8/19/13 12:58 PM, tim Rowledge wrote:
>
> Seems to me there are two rather different usages here
> a) an alert within the normal UI, to let you know something odd happened
> b) a diagnostic when debugging where you need a 'bigger' alert.
>
> For b) a 100mS simple delay is probably perfectly fine. I've done debugging
> where it would be really nice for there to be a good way of 'interrupting
> the delay' to get in to the problem process; an associated visual widget to
> click on or something.
>
> For a) a delay that holds up everything is not a good idea. Some form of
> alarm (like the morphicalarm is supposed to be) that keeps the UI moving is
> going to be least annoying. I think it's likely that there are better
> feedback concepts than simply flashing the morph.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> A paperless office has about as likely as a paperless bathroom.
>
>
>
>
>
>
>
>


More information about the Squeak-dev mailing list