halosghost / colortemp Goto Github PK

colortempd's long-running daemon option needs to listen for messages so that it knows what to do.

• Fork off
• Calculate and set temperature gradually
• Populate sane default values for initial runtime
• #6
• Open a named pipe, listen on it for incoming messages
• Parse messages (msgpack format?)

Our config must contain at least the following options:

• latitude
• longitude
• sunset
• sunrise
• dd_temp -- temperature at dawn and dusk
• noon_temp -- temperature at noon
• night_temp -- temperature between dusk and dawn
• max_steps -- maximum number of steps allowed between dawn-noon and noon-dusk
• temp_step -- temperature to increase by per step

The config needs to be flushed when execution ends (cleanup or failout), and read in. If config does not exist on run, use default values; if it does exist, read in specified values and then continue.

Hi, I was using your sct version since 18th November. It works perfectly fine for me, but I just got "annoyed" not having a daemon, so suddenly go-sct appeared in my search results.
It's having go as a huge dependency, which (right now) is fine for me.

Thank you so much,
norpol.

Simple zsh tab-completions would be great to have; they would not need to be complex at all to cover all the options; but having them is always positive.

Before we do much of anything else, we need to add option handling.

I have mulled this over for a while now, and I think I will go with getopt-style options instead of the growing-in-prevalence systemd-style verbs. However, if anyone wants to discuss this further, just post a note.

At the moment, colortempd is still just one-shot. The eventual goal is to (even though we will keep the one-shot option) have colortempd fork off into a long-running dæmon, and to create colortempctl to control the daemon.

• #2
• #3
• Create colortempctl to simplify sending messages to colortempd

I have learned my lesson. Alternative build systems do not yet have enough to offer over plain (or GNU) make. Switch back to simplify life for everyone.

Right now, we can only do temperatures between 1 and 10.5 thousand K, and the temp table we use only functions sanely at 500K increments. This means we can only represent 20 different temperatures correctly; everything in-between gives outrageously odd results.

It would be great if we could create an algorithm mapping color temperatures to RGB values which would let us pick (nearly) arbitrary integral values in the same range.

@pid1 has shown interest in this.

Related Reading