Ghostty-driven chrome theming and auto theme settings#85
Conversation
Assisted-by: pi:gpt-5.4
Assisted-by: pi:gpt-5.4
Assisted-by: pi:gpt-5.4
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 78bfbe52f4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| } | ||
|
|
||
| func updateAppearance(themeInfo: GhosttyThemeInfo, chromePalette: MoriChromePalette) { | ||
| window?.backgroundColor = chromePalette.windowBackground.nsColor |
There was a problem hiding this comment.
Preserve transparent workspace background on theme refresh
syncGhosttyAppearance now calls adapter.syncWorkspaceWindowAppearance(window) before refreshGhosttyThemeBackgrounds, but updateAppearance unconditionally resets window.backgroundColor to an opaque chrome color here. In configurations where Ghostty enables translucent/glass window backgrounds (background-opacity < 1 or glass blur), the adapter intentionally sets a near-clear background; this assignment overwrites it on startup/reload/appearance changes, so terminal translucency is lost after theme sync. Please avoid overriding the window background when transparent mode is active (or reapply the Ghostty window appearance after chrome updates).
Useful? React with 👍 / 👎.
- Collapse GhosttyConfigFile.set() two-pass dedup into single compactMap scan - Merge GhosttyThemeSelection.configValue .light/.dark cases via activeTheme - Merge selectedThemeSummary .light/.dark view cases via theme(for:) - Replace activeThemeTarget ternary with explicit switch (.auto case visible) - Inline single-use moriSRGBComponents into moriRelativeLuminance - Delete plan.md from repo root Assisted-by: claude-code:claude-sonnet-4-6
syncWorkspaceWindowAppearance correctly sets the main window to nearly-transparent for non-opaque themes, but the subsequent refreshGhosttyThemeBackgrounds → MainWindowController.updateAppearance call overwrote it with the solid chrome palette background, cancelling out the opacity effect. Guard the backgroundColor update so it is skipped when themeInfo.usesTransparentWindowBackground is true; syncWorkspaceWindowAppearance remains the sole owner of the window background in that case. Assisted-by: claude-code:claude-sonnet-4-6
When backgroundOpacity < 1, sidebar, companion pane, and root split view now clear their layer backgrounds instead of painting solid palette-derived colors, letting the window's visual effect show through. Assisted-by: claude-code:claude-sonnet-4-6
SidebarContainerView painted a solid sidebarBackground regardless of opacity. Added isTransparent to MoriChromePalette (set from themeInfo.usesTransparentWindowBackground) so the SwiftUI background modifier can switch to Color.clear when transparency is active. Assisted-by: claude-code:claude-sonnet-4-6
Instead of setting surfaces to Color.clear (making them holes), apply backgroundOpacity as alpha to all surface palette colors in the builder. This makes sidebar, companion pane, and root split tint-transparent at the same opacity level as the Ghostty terminal, so they blend consistently over the wallpaper. Removes isTransparent from MoriChromePalette and all isTransparent ? .clear ternaries — opacity is now carried by the palette colors themselves. Assisted-by: claude-code:claude-sonnet-4-6
Summary
Testing