1

In order to toggle light and dark color schemes, I've set up two units that run a script that creates a symbolic link to my termite configuration file, when triggered by their respective timers. The linked file contains the appropriate light or dark scheme, and then when termite receives SIGUSR1, it reloads its configuration. All good.

$ systemctl --user list-timers
NEXT                         LEFT          LAST                         PASSED  UNIT             ACTIVATES
Mon 2018-11-05 14:20:00 CET  9min left     Mon 2018-11-05 14:10:13 CET  1ms ago brightside.timer brightside.service
Mon 2018-11-05 16:00:00 CET  1h 49min left n/a                          n/a     darkside.timer   darkside.service

$ cat ~/.config/systemd/user/brightside.timer
[Unit]
Description=Ensure a bright colorscheme every ten minutes during the day.

[Timer]
OnCalendar=*-*-* 09..15:0/10

[Install]
WantedBy=timers.target

So brightside.service links termite_light.conf to ${XDG_CONFIG_HOME}/termite/config every 10 minutes during the day. Then, darkside.timer takes over:

[Timer]
OnCalendar=*-*-* 16..23:0/10
OnCalendar=*-*-* 00..08:0/10

Now I'd like to override either or both of the timers by creating or removing symbolic links to either ~/.config/systemd/user/{dark,bright}side.d/override.conf using a shell script. Ultimately I want to have a programmable timer setup like on an electric socket timer. (But with the advantage of changing the seasonal daytime length). The idea here is to provide a four-way toggle:

  • bright [manual]
  • bright [automatic]
  • dark [manual]
  • dark [automatic]

If I set dark [automatic] mode during daytime, the script first sets the dark scheme. Then it should temporarily override brightside.timer or stop the timer so that we're not switching back immediately. But how do I make it so that by the time darkside.timer ends, brightside.d/override.conf got removed, or brightside.timer is started again?

I previously used AssertPathExists and empty files in /tmp to override the timer. Maybe that's still the best solution, because I'd probably be reloading the daemon to incorporate the override.conf, wouldn't I?

Improve this question
3
  • What problem are you trying to address by notifying termite of a colour scheme every 10 minutes? Commented Nov 7, 2018 at 7:22
  • @roaima yes that's an arbitrary resolution and no it doesn't address the problem. I probably need to trigger it after suspend.target and such. Commented Nov 7, 2018 at 17:52
  • What about setting the config (1) at boot, and (2,3) at sunrise/sunset or whatever switchover points you've determined. No need for complicated timers then, and you won't need to keep overwriting the config every few minutes. Commented Nov 7, 2018 at 18:15

1 Answer 1

Reset to default
1

I guess one option would be to introduce two more timers (and services) that would fire once a day at the switching hours only (9am and 4pm) and have those services remove any overrides and re-enable timers as needed to remove a manual setting and return to an automatic one.

But I really think you're over-engineering this to some extent... While it's laudable that you're managing to implement this all without a single shell script and you're making great use of systemd features such as the very flexible calendar specifications of timer units and the convenience of override files, I think encoding the state of the system (dark vs. bright, manual vs. automatic) in systemd doesn't really simplify your overall solution.

As an exercise, try to imagine if your combinations were much larger. For instance, what if you had not only two color schemes per day, but three? Or if you had four different "bright" colorschemes, one for each season? Or if you wanted to adjust times for the switch based on sunrise/sunset times?

It seems to me that having a single systemd timer + service to switch colorschemes would be more appropriate, having that service invoke a script (shell, python, etc.) that would pick colorscheme, taking into account the current time but also manage existing overrides (using state files somewhere in /run perhaps.)

Such a system would be simpler overall and much more extensible than you can build with systemd units alone.

Improve this answer
1
  • Unfortunately I'm not really interested in such a plural colorscheme setup :-) I was thinking about sending a USR1 signal using a service/timer setup to a daemon program that then toggles whatever scheme is active. I think it would prove to be more interesting to make it depend on other units/targets. I'll try to write make a gist with some new ideas next week (I'll be offline for a few days). I'm looking at PropagatesReloadTo at te moment. Commented Nov 7, 2018 at 18:56

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.