Attached are patches for the changes described below. Bugs fixed:
1. Turning off blink or seconds with the other already off sets the update time to the second of the minute the change occurred. This makes it appear the clock is up to 1 minute slow after the change. This is because the wakeup time is set to 1 minute from the toggle event instead of the start of the next minute. 2. Dclock waits for child processes to finish playing audio, so the display doesn't update during that time. This also causes update time to creep as above when seconds and blink are off because the wakeup time is set to 60 Sec. from the finish of the child process instead of the first second of the next minute. 3. Unless seconds are active, you can't turn on blink without waiting for the next minute timeout -- which may appear random due to (1). The toggle function fails to reset the frame rate to 1 Sec until the next timeout -- up to a minute away. 4. Toggling blink off, then on with seconds off -- also seconds with blink off -- in the minute of the alarm/bell causes the alarm/bell to sound again. This is caused by the expectation dclock will wake only once during the minute of the alarm when the update rate is set to 60 Sec. XEvents causing redisplay will set it off as will additional improperly controlled wakeups from the previous 1 Sec frame rate. The fix is to compare against calendar time, not time of day and to compute the next alarm/bell time when servicing the existing one. 5. The alarm flashing goes on forever. toggle_reverse_video() calls show_time() which then calls toggle_reverse_video() again the alarm is flashing. Recursion can build on fast systems or on those with ulimit(1) for stack set low, until dclock crashes on stack overflow or SEGV. A control to toggle reverse video once per frame until a counter expires fixes this. Alarm flashing gets its own frame rate to control the flash rate instead of racing. 6. Toggling reverse video repeatedly soon causes the reverse display to become corrupt and unreadable. This is magically fixed by removing the recursion already causing other problems. 7. When seconds or blinking are enabled, some updates get missed. Instrumentation shows 2 frames processed in the same second, then, none the next. This appears to be a truncation of the wait time, so it is 1 TICK quicker than is desired. It's fixed by waiting well more than a tick into the next second to wake -- 10mS or even 20mS are not noticeable but work well to avoid missed Seconds. 8. If there is a failure in audio play, dclock begins using the X bell exclusively. Dclock must be restarted to get audio back. There is little penalty for continuing to try audio and falling back to X bell on each failed attempt, so that is the new behavior. Features added: 1. Ringing the bell twice at the top of the hour is limiting. A setting, "singleBell", when true, makes dclock chime just once at each bell event instead of the arbitrary two at the top of the hour, one at the bottom. Scripting an audioPlay executable for advanced chimes is more convenient with this set TRUE. 2. An "hourlyBells" resource defaulting to 2 has been created to allow quarter bells (when set to 4.) This indicates the number of times per hour bells should play. The right script in dclock*audioPlay could chime like Westminster or strike the hour like a cuckoo clock. (Yes, Westminster starts at 25 seconds before the hour, because the first stroke of the hour must be within 1 Sec of the start of the hour. No, this change does not include that capability. Precession parameters could be included in hourlyBells.) 3. Man page edited to reflect changes above and correct formatting.
Dclock-2.2.2.1.tbz
Description: application/bzip-compressed-tar
