This is just waaay too much.

- It makes little sense to talk about a "public API" in Squeak. All 
methods are visible and executable from anywhere. To think that some 
subset of all methods have been vetted and will never do anything 
unpleasant is not supported by the facts.

- If you look at the senders of flash in the image, it pretty much all 
about , "I just asked a tool to do something and it could not. Oops!" No 
need for anything fancy here - just DTSTTCPW.

- The introduction of alarms made me nervous. I understand delays, but 
alarms are a gray area. How do they work? Will they do what I think they 
will? In this case, they do *not*. If we go back to my example:

m _ (1 to: 10) collect: [ :i | Morph new position: (i at i*75); openInWorld]

m do: [ :e | e flash]

Using the alarming version of #flash, we see the first morph flash ever 
so briefly. Each successive morph flashes for a longer time, until the 
last one stays inverted for 600 ms. Huh!

If you look at: WorldState>>triggerAlarmsBefore:, you see the claim:

"Trigger all pending alarms that are to be executed before nowTime."

when, in fact, it triggers one at most:

     triggered := OrderedCollection new.
     self lockAlarmsDuring: [:pending |
         (pending isEmpty not and: [pending first scheduledTime < nowTime])
             ifTrue: [triggered add: pending removeFirst]].
     triggered do: [:alarm | alarm value: nowTime].

makes me want to

Smalltalk destroyAllComments ;-)

Cheers,
Bob

On 8/19/13 5:56 AM, Marcel Taeumel wrote:
> Hi! :)
>
> One point against blocking the event loop: You never know who will call
> #flash as it is public API. It is not guaranteed that the flashing morph is
> "visible" at all and not occluded by some other morph. Then, strange short
> image freezes will be noticed.
On 8/19/13 6:07 AM, Marcel Taeumel wrote:
> Here a better version:
>
>   (self valueOfProperty: #colorBeforeFlashing ifAbsent: [self color])
>      in: [:c |
>        self setProperty: #colorBeforeFlashing toValue: c.
>        self color: ((c ifNil: [Color white]) alpha: 1) negated.
>        ActiveWorld displayWorldSafely.
> 		
>        self
>          removeAlarm: #color:;
>          removeAlarm: #removeProperty:.
>        self
>          addAlarm: #color: with: c after: 100;
>          addAlarm: #removeProperty: with: #colorBeforeFlashing after: 100].
>
> I am not exactly sure, why an explicit call to the render loop is needed...
> But this way, it works without blocking the event loop. This "ActiveWorld
> displayWorldSafely" is still annoying...
>
> Best,
> Marcel
>
>
>
> --
> View this message in context: http://forum.world.st/computers-too-fast-these-days-tp4704067p4704117.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130819/33fc1a69/attachment.htm