signal-lamp

README

* signal lamp

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:

#+begin_src shell
go install github.com/chelmertz/signal-lamp
#+end_src

Run it, to create config folders:
#+begin_src shell
signal-lamp
#+end_src

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

*** Configuration

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

#+begin_src toml
[dark]
gnometerminal = "dark"
vscode = "Ayu Mirage"

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

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:
#+begin_src shell
signal-lamp -cycle
#+end_src

*Query* the current theme:
#+begin_src shell
signal-lamp -query
#+end_src

*Set* the current theme:
#+begin_src shell
signal-lamp -theme dark
#+end_src

** 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

#+begin_example
[signallamp]
command=signal-lamp -cycle
full_text=signal lamp
#+end_example

** 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