You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature request: wallpaper (background image) support in the new theme system #5661
The new theming system in the nightlies (.1025+) is excellent — I moved my
whole custom palette into it the day it appeared. This is a request for the
one visual layer it can't express yet: a background image behind the canvas.
What I built (works today, via CSS patching)
A desktop wallpaper that sits under the whole app, with the existing glass
surfaces doing all the work of keeping content readable. The composer is the
star: its translucent glass lets the image ghost through the prompt box, and
the native glass-opacity slider already gives users the control they need.
Mechanically it's small — which is why I think it would make a clean native
feature:
One image layer on the root (I use html::before, position: fixed, cover, with a theme-colored gradient over it to set the ghosting level —
the equivalent of a wallpaper opacity setting).
Four stacked bg-background/80 layers currently bury it (the inner flex
container, the scroll container, main, and body). They need to be
transparent when a wallpaper is active — everything above them (cards,
bubbles, composer, popovers, sidebar) keeps its own paint and stays
readable with zero further changes.
That's the entire mechanism. No component changes needed — the app's existing
glass design language already composes beautifully with an image behind it.
Proposed shape
An optional field on the theme file (or a standalone appearance setting):
{
"version": 1,
"name": "Deep Veil",
"appearance": "light",
"colors": { /* ... */ },
"wallpaper": {
"image": "<data URI or file path>",
"opacity": 0.15, // how much image shows through the canvas color"fit": "cover",
"position": "center"
}
}
opacity as "image strength" (canvas color over image) matches how people
reason about wallpapers, and keeps every theme readable by default.
The glass-opacity setting already covers the surface-translucency half.
Import/export keeps working — a theme with its wallpaper travels as one
file (data URI), which is a lovely property for sharing themes.
Happy to share the working CSS, screenshots, or test nightlies. Thanks for
the theme system — funny how being able to theme it the way I want made me use
t3code a lot more.
I'd like to put up a PR for this. The minimal slice I have in mind:
An optional wallpaper field on ThemeFile (image data URI, opacity, fit, position). Optional, so version-1 files, import/export, and every existing theme keep working unchanged.
useTheme sets --theme-wallpaper-* variables and a root class when the active theme carries one.
index.css adds a fixed root image layer (a theme-colored gradient over the image implements the opacity control), and under that root class the covering bg-background/80 / body layers go transparent. Everything above them — cards, bubbles, composer glass, popovers, sidebar — keeps its own paint and stays readable as-is.
No theme-editor UI in the first slice: wallpapers arrive via theme import; editor UI as a follow-up.
One question before I build it: as a data URI the image would live inside the t3code:themes:v1 localStorage entry, which has a real size budget. Is a documented cap (say ~2 MB, with a friendly import error) acceptable for a first version, or would you prefer different storage for the image? Happy to go either way.
Draft PR up at #5911 — the minimal slice described above (wallpaper field on ThemeFile, root hook + body chrome paint, no editor UI). On the storage question: the image cap (192 KB base64) keeps any wallpapered theme file inside the existing 256 KB MAX_THEME_FILE_BYTES import budget, so no limits change.
Activity
Williawar commentedon Aug 8, 2026
I'd like to put up a PR for this. The minimal slice I have in mind:
wallpaperfield onThemeFile(imagedata URI,opacity,fit,position). Optional, so version-1 files, import/export, and every existing theme keep working unchanged.useThemesets--theme-wallpaper-*variables and a root class when the active theme carries one.index.cssadds a fixed root image layer (a theme-colored gradient over the image implements theopacitycontrol), and under that root class the coveringbg-background/80/ body layers go transparent. Everything above them — cards, bubbles, composer glass, popovers, sidebar — keeps its own paint and stays readable as-is.One question before I build it: as a data URI the image would live inside the
t3code:themes:v1localStorage entry, which has a real size budget. Is a documented cap (say ~2 MB, with a friendly import error) acceptable for a first version, or would you prefer different storage for the image? Happy to go either way.Williawar commentedon Aug 9, 2026
Draft PR up at #5911 — the minimal slice described above (
wallpaperfield onThemeFile, root hook + body chrome paint, no editor UI). On the storage question: the image cap (192 KB base64) keeps any wallpapered theme file inside the existing 256 KBMAX_THEME_FILE_BYTESimport budget, so no limits change.