The use case for this helplet is pretty straight forward -- trying to match the recording of a text with a timely constraint. Which might sound easy at the first glance, mostly until it sinks in that the problem is not only being too long, i.e. needing too much time but also being too short, i.e., being done before the time is over. Turns out, it helps a lot to have a countdown clock running which has some not-so-standard-features:
- The boring stuff This is what you might expect: I enter the seconds to count down, I enter how many seconds before the countdown actually starts I want to start my clock (to get a recording running, etc), and at which thresholds I want color changes to green, amber, and red background colors.
- Floats-on-top. I can work in other windows, i.e. the playout system or scroll my text -- but not lose sight to my clock. Keep in mind that mouse clicks might be audible in the recording and thus there should be as little user interaction necessary as possible.
- Doesn't keep focus. I control other programs with the keyboard and I don't want to worry about my keystrokes not having effect since they won't make it to that other program since my fuckin' countdown holds Z-Order 0 and thus keeps all keystrokes to itself. Turns out the easiest way to do this is hide the window, ask
getForegroundWindow()who's been catching the ball and then show my window followed by
setForegroundWindow()back to the window below mine.
- Visibility I might be focused on the text I'm recording -- I don't really have time to stare at the numbers counting down. But without focussing on that window, I will be mostly able to track color changes, especially of the background color. Thus there's a number of color changes implemented:
As the pre-countdown is running, the remaining time is set in a white font on a black background. The timer is started by clicking into the countdown-label.
MD5 (countdown-bin.zip) = 31a2fdcf28c62084dde84da3c315fc9a