/signal-lamp

Theme switcher

Primary LanguageGoMIT LicenseMIT

signal lamp

2024: See a better approach at https://iamnearlythere.com/dark-mode-ubuntu-i3/

Changes the theme of your applications in one fell swoop.

Input a theme, run your definitions of that theme and apply them to running programs.

Everything is accessible through scripts. Idempotent one off script, not a daemon.

Installation

Install the program:

go install github.com/chelmertz/signal-lamp

Run it, to create config folders:

signal-lamp

Configure ~/.config/signal-lamp/signal-lamp.toml, see the next section.

Configuration

This is an example config (see signal-lamp-example.toml):

[dark]
gnometerminal = "dark"
vscode = "Ayu Mirage"

[light]
gnometerminal = "light"
vscode = "Default Light+"

When there are two or more themes defined (dark and light here, you can name these anything), we cycle between them.

CLI commands

Cycle theme, and save the new to the config file:

signal-lamp -cycle

Query the current theme:

signal-lamp -query

Set the current theme:

signal-lamp -theme dark

Adding theme support for more things

Implement a func(newName string) error callback and call it in changeThemes() .

Caveat

These scripts work for me, on a standard Ubuntu installation with a bunch of X related scripts added. A personal checklist of what I want to support:

  • [X] vscode
  • [ ] idea
  • [X] gnome terminal profile
  • [ ] bat
  • [ ] delta
  • [ ] powerline
  • [ ] doom emacs

contrib

i3blocks for toggling & showing status

[signallamp]
command=signal-lamp -cycle
full_text=signal lamp

Using themes, rather than only “dark & light mode”

All themes are configured in $XDG_CONFIG_HOME/signal-lamp/signal-lamp.toml.

The wanted theme setting is stored in $XDG_CONFIG_HOME/signal-lamp/wanted and contains a single string, matching one of the available themes.

Design iterations

  1. Toggle between light & dark mode
    • always dark or light for all applications
    • no support for N themes
  2. Toggle between named themes in a file
    • support for N themes
    • hardcoded target (vscode, gnome terminal) themes in the “input theme name => theme for application X” files, which are possibly compiled ones
  3. … 2, but extracting “input theme name => theme for application X” into configuration files
    • “change theme in gnome terminal to X” can be a standalone script
    • natural way towards the decoupled “list all themes for application X”, “apply theme Y for application X”
    • not messy to add support for one more application
    • still very messy when applying the state
      • I would want to save the changes into my dotfiles repo
      • for example, persisting the emacs theme can be done in a million places, all equally disgusting to those that manages their config
      • portability between distros etc goes out the window
      • … still, this is the best I’ve got. start small and iterate?
  4. “list themes available for application”, customizable “apply theme for application” that takes input from either a TUI or saved configuration
    • disregarding “list themes” - far to expensive to implement, even for vscode
  5. “apply theme for application”
    • a) all application specific scripts takes an application theme
    • b) a program in front (signal-lamp) of all application specific scripts
      • it keeps the state to be able to cycle themes
      • it can take any theme as input and “translate” it to application specific scripts
  6. started implementing 5b) as different scripts, will implement them as go files/libraries instead
    • nobody will ever care about this coupling, if someone wants to support something new, they’ll have to build signal lamp again and either pull the code or upstream it (yay)
    • decoupling via processes would require somewhat unique names for all scripts, like sl-gnometerminal, which is ugly
    • all helpers (like proc()) would need to have been copy- & pasted
    • now, we can treat the toml configuration with stricter types (because of the tighter coupling, we know exactly which applications we should support)
    • if anybody is interested in using signal-lamp/gnometerminal as a go library, go ahead
    • https://pkg.go.dev/github.com/hashicorp/go-plugin#section-readme could be useful for a more significant program