Repository navigation
[Feature]: Live system-theme sync on Linux (read colors from a well-known file, like Omarchy's ~/.config/omarchy/current) #10448
Description
Activity
Thanks for the write-up — this is a real workflow, and #2175 is prior-art notes only, not a duplicate.
This already exists upstream as environment themes, shipped in #8569 (docs: Appearance and themes). That work was motivated by Omarchy but is not Omarchy-specific.
What to use today
- Have matugen / pywal / a hook atomically write a small T3 palette to
~/.t3/userdata/themes/<id>.json(or$T3CODE_HOME/userdata/themes/). Keep the filename stable across recolors. - Seeded form is enough:
{ "name": "Wallpaper", "appearance": "dark", "canvas": "#1a1b26", "accent": "#7aa2f7" }- Select that card in Settings → Appearance, or run
t3 theme set wallpaper(ort3 theme set /path/to/theme.json) once. The server watches the directory and connected web/desktop clients retint on rewrite (~100ms). Missing or invalid files are skipped; the rest of theming is unchanged.
t3 theme setis the programmatic re-import path. It copies into the watched dir (a source symlink is fine; a symlink insidethemes/is rejected). Re-runningsetalso re-applies the default for clients that later picked something else.Omarchy’s intended integration is the same shape: generate T3 JSON and publish it (see omacom/omarchy#8784), not an in-app
~/.config/omarchy/currentreader.What is not in tree (and was already declined)
Ask Status Watch an arbitrary path ( ~/.config/t3code/theme.json, Omarchycurrent)Not implemented. Distro-specific desktop watchers were closed: #7669, #8165 VS Code *-color-theme.jsonon the live publish pathImport Theme still converts that; t3 theme set/ the watcher only accept T3 export JSON or the seeded form aboveDesktop --theme-file/t3code://import-themeNo theme-import CLI, IPC, or deep-link. #8080 was closed pending an import/trust policy; #8079 is still open Suggested next step: point the generator at
~/.t3/userdata/themes/(or wrap it witht3 theme set). If that format or path is unusable, say so here — accepting VS Code JSON on the publish CLI would be a smaller, separate change than another file watcher.- Have matugen / pywal / a hook atomically write a small T3 palette to
Thanks for the detailed pointer — the environment-themes path worked exactly as described, no fork needed.
Wired matugen's post-wallpaper-change hook to write the seeded form straight to
~/.t3/userdata/themes/wallpaper.json(stable filename, atomic overwrite):{ "name": "Wallpaper", "appearance": "dark", "canvas": "#080a0c", "accent": "#99ccfa" }Selected "Wallpaper" once in Settings → Appearance and it's now retinting live on every wallpaper change. Closing this out — thanks again.
Title: [Feature]: Live system-theme sync on Linux (read colors from a well-known file, like Omarchy's
~/.config/omarchy/current)Problem
Custom themes currently only get into T3 Code via Settings → Appearance → Import Theme, which opens a native file picker and copies the selected VS Code-style theme JSON into app storage. That's fine for a one-off theme, but it breaks any workflow where colors are generated dynamically — e.g. matugen deriving a Material You palette from the current wallpaper and regenerating it on every wallpaper change. Each regeneration currently requires manually reopening the file picker and re-selecting the same file.
Prior art
The
t3code-omarchyfork already solved this for Omarchy specifically (see #2175, section F2 "Omarchy System Theme Projection"):~/.config/omarchy/current.omarchywhen that state is available.Omarchy's
~/.config/omarchy/currentis itself just the output of a matugen-style generator, so this is effectively "watch a file matugen (or any wallpaper-colors tool) writes, and live-apply it" — not Omarchy-specific plumbing.Request
Add an equivalent, generalized mechanism upstream (not tied to Omarchy specifically):
~/.config/t3code/theme.jsonor similar) for a small color-token JSON.This would let any external tool (matugen, pywal, wpgtk, Omarchy itself, a custom script) drive T3 Code's theme the same way they already drive terminals, window managers, and other apps, without needing app-specific integration code or a fork.
Alternative / smaller ask
If a generic file-watch mechanism is too much scope, even exposing the Import Theme action via a CLI flag or IPC/deep-link (
t3code://import-theme?path=...) would let external tools trigger re-import programmatically instead of requiring a manual click-through each time.