That sounds logical to me.  It makes me curious, though, what is the
purpose of doing this adjustment in the first place?  For in case the
image was exited and restarted later?  If only for that, then on every
world cycle seems unnecessarily inefficient..

On Fri, Apr 8, 2016 at 11:37 AM, marcel.taeumel <Marcel.Taeumel at hpi.de> wrote:
> Hi, there!
>
> There is this method WorldState >> #adjustAlarmTimes: to correct larger
> drifts between the nowTime and the lastAlarmTime. A check and this
> correction is performed in *every *world cycle.
>
> Here is, where it works fine:
> 1. You set an alarm to go off in 5 seconds.
> 2. You immediately close the Squeak image.
> 3. You wait a minute.
> 4. You open Squeak again.
> 5. You wait 5 seconds.
> 6. Alarm goes off.
>
> I think we can agree that a closed Squeak image freezes all Morphic
> behavior.
>
> Now, here is, where it seems annoying:
> 1. You set an alarm to go off in 5 seconds.
> 2. You immediately start a longer running operation from the workspace in
> the UI process.
> 3. You wait that operation to complete. Maybe some minutes.
> *4. You still have to wait 5 seconds.*
> 5. Alarm goes off.
>
> This is not acceptable. Think of larger alarm delays. We cannot just ignore
> the fact that time has passed while working inside the image. It think we
> should only adjust alarm times when:
>
> - Starting a Squeak image.
> - Entering a Morphic project.
>
> Because in both cases, the respective Morphic world freezed. Any thoughts on
> this?
>
> Best,
> Marcel
>
>
>
> --
> View this message in context: http://forum.world.st/Adjusting-Morphic-Alarm-Times-tp4889145.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>