Allow configuring thresholds for colors on elapsed time for estimated time

[Zocker1999NET]

Is your feature request related to a problem? Please describe. When a presentation is mandatory at my university, I need to meet the assigned time +- 2 minutes. To deviate more than 2 minutes is considered an error.

Describe the solution you'd like Let users configure when which is color is to appear. This would allow me to configure the timer so that:

• it fades to green while approaching 18 min
• then fades to orange while approaching 20 min
• and finally fade to red while approaching 22 min

(The reasoning is: I estimate that after looking at the timer that I will still need at least a minute to end my presentation properly.)

Describe alternatives you've considered At least knowing when the colors change would already help. I tried to find that info in the man page or the application itself (without reading the code), but I could not find it. Still, letting users to configure it, even by just setting the values in the config file, would drastically help.

[Cimbali]

This seems like a reasonable request :)

Currently, the times are hard-coded:

https://github.com/Cimbali/pympress/blob/0218a2682c7e6cf215bd754cd29a9d9b184ea26f/pympress/talk_time.py#L71-L76

So:

• 5 minutes before the end, start fading from default to green ("reached" color)
• 0 remaining, blink for 5 seconds
• start fading to orange ("info" color) over 2.5 minutes
• then fade to red ("warn" color) over 2.5 minutes
• After that remain solid red

I haven't always been convinced by the whole fading thing myself, nor by the necessity of blinking.

How about being able to specify start-end time of styles/fading? Something like:

green = -2:00 to 0 # expressed in time relative to the expected end
orange = 0 to 120 # can use seconds too
red = 2:00 # this is how you should specify a color starting at a time without fading
blink = -10 to 10 # blink 20s around target time
blink = # Alternately, leave an entry empty to disable

[Cimbali]

To be fair I think the remaining time convention is confusing too. "-2" for "2 before the end" seems like a more sensible convention, i.e.time relative to the end (in the same direction).

We could also allow values like "5%" that will adapt better to varying durations.