Match the macOS app appearance to the selected theme by huacnlee · Pull Request #58902 · zed-industries/zed

huacnlee · 2026-06-09T07:45:26Z

Closes #5049.

When the system is in light mode but Zed uses a dark theme, the macOS window chrome — the window border and the titlebar — is rendered light, leaving a pale, low-contrast edge that makes the window look washed out. Zed's own content renders correctly; the affected chrome is drawn by AppKit, not Zed.

Why it happens: NSWindow conforms to NSAppearanceCustomization, so a window's appearance is inherited app → window → view and resolved through effectiveAppearance unless an explicit appearance is set. Zed never set one, so every window inherited the system appearance and AppKit drew the chrome for light mode regardless of the dark theme.

The fix uses the override AppKit provides for exactly this: set NSApplication.appearance app-wide, so every window inherits it. VSCode (window.systemColorTheme) and JetBrains IDEs do the same.

GPUI

Add App::set_window_appearance(Option<WindowAppearance>), the setter paired with the existing App::window_appearance() getter. Some(_) forces a light/dark appearance; None clears the override and follows the system again.
macOS sets NSApplication.appearance (None → nil); no-op on other platforms.
Demo: cargo run -p gpui --example window_appearance.

Zed

An explicit light/dark theme (or a static theme) forces the matching chrome; System follows the OS.
Wired once at startup via a global settings observer, so every window — including the settings window — stays in sync.

Before	After

References: NSAppearanceCustomization · NSApplication.appearance

Release Notes:

Fixed the macOS window border and titlebar not matching the selected theme when the system appearance differed (for example, a dark theme under a light system theme). (#5049)

…ance Add `App::set_window_appearance(Option<WindowAppearance>)`, the setter paired with the existing `App::window_appearance()` getter. `Some(_)` forces a light/dark appearance; `None` clears the override and follows the system again. On macOS this sets `NSApplication.appearance`, which controls the native window chrome (the window border and titlebar) of every window, so a dark-themed app no longer shows a light, washed-out window border when the system is in light mode. Setting it on the application (rather than per window) matches AppKit's app-wide appearance model, so every window inherits it. No-op on other platforms. Demo: `cargo run -p gpui --example window_appearance`. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Drive App::set_window_appearance from the theme at startup so the native window chrome (the window border and titlebar) matches the selected theme. An explicit light/dark theme (or a static theme) forces the matching appearance; System follows the OS. Wired via a global settings observer, so every window — including the settings window — stays in sync. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

huacnlee · 2026-06-10T10:49:52Z

Furthermore, this is also very important. For example, my current gpui-component implementation of a native menu for macOS and Windows is still using the light menu in dark mode because the window doesn't change the NSWindow's appearance information.

For example in Ghostty is correct:

Veykril

I don't think the example pulls its weight here, but otherwise lgtm!

huacnlee · 2026-07-28T01:47:41Z

Is there any things need me to change? or I just waiting to merge?

Veykril · 2026-07-28T07:36:39Z

Lets remove the example, otherwise this is good to go I think

huacnlee · 2026-07-28T08:16:25Z

done

Veykril

Thanks!

…-industries#61789) ### Objective PR zed-industries#58902 made native macOS window chrome follow the selected theme, but AppKit can synchronously invoke `viewDidChangeEffectiveAppearance` while the settings observer holds an `App` borrow. `handle.update` then fails with `RefCell already borrowed`, leaving `Window::appearance()` and its observers stale. ### Steps to reproduce 1. Set Zed's theme mode to Dark. 2. Set macOS Appearance to Light. 3. Change Zed's theme mode to System. 4. Notice that the window chrome switches to light, but Zed's UI remains dark. https://github.com/user-attachments/assets/f91962cc-76ba-4d8e-b587-2a2343f365ba ### Expectation Zed should switch to its configured light theme when returning to System mode. ### Solution Defer `Window::appearance_changed` to the foreground executor so the current `App` borrow finishes before refreshing the cached appearance and notifying observers. ### Testing - Added a regression test. ### Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [ ] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Release Notes: - N/A

…-industries#61789) ### Objective PR zed-industries#58902 made native macOS window chrome follow the selected theme, but AppKit can synchronously invoke `viewDidChangeEffectiveAppearance` while the settings observer holds an `App` borrow. `handle.update` then fails with `RefCell already borrowed`, leaving `Window::appearance()` and its observers stale. ### Steps to reproduce 1. Set Zed's theme mode to Dark. 2. Set macOS Appearance to Light. 3. Change Zed's theme mode to System. 4. Notice that the window chrome switches to light, but Zed's UI remains dark. https://github.com/user-attachments/assets/f91962cc-76ba-4d8e-b587-2a2343f365ba ### Expectation Zed should switch to its configured light theme when returning to System mode. ### Solution Defer `Window::appearance_changed` to the foreground executor so the current `App` borrow finishes before refreshing the cached appearance and notifying observers. ### Testing - Added a regression test. ### Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [ ] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Release Notes: - N/A (cherry picked from commit a11083f)

…58902) Closes zed-industries#5049. When the system is in light mode but Zed uses a dark theme, the macOS window chrome — the window border and the titlebar — is rendered light, leaving a pale, low-contrast edge that makes the window look washed out. Zed's own content renders correctly; the affected chrome is drawn by AppKit, not Zed. Why it happens: `NSWindow` conforms to `NSAppearanceCustomization`, so a window's appearance is inherited app → window → view and resolved through `effectiveAppearance` unless an explicit appearance is set. Zed never set one, so every window inherited the *system* appearance and AppKit drew the chrome for light mode regardless of the dark theme. The fix uses the override AppKit provides for exactly this: set `NSApplication.appearance` app-wide, so every window inherits it. VSCode (`window.systemColorTheme`) and JetBrains IDEs do the same. <img width="2600" height="1346" alt="after-light" src="https://github.com/user-attachments/assets/c31376af-8f51-4c36-a62f-55714f63b59c" /> ## GPUI - Add `App::set_window_appearance(Option<WindowAppearance>)`, the setter paired with the existing `App::window_appearance()` getter. `Some(_)` forces a light/dark appearance; `None` clears the override and follows the system again. - macOS sets `NSApplication.appearance` (`None` → `nil`); no-op on other platforms. - Demo: `cargo run -p gpui --example window_appearance`. ## Zed - An explicit light/dark theme (or a static theme) forces the matching chrome; `System` follows the OS. - Wired once at startup via a global settings observer, so every window — including the settings window — stays in sync. | Before | After | | --- | --- | | <img width="3630" height="1878" alt="before-light" src="https://github.com/user-attachments/assets/44c9ab66-c0cf-433a-93b0-17446b34a284" /> | <img width="3686" height="1832" alt="SCR-20260609-nzjk" src="https://github.com/user-attachments/assets/32b0412b-0913-4e68-acba-bf39dcb6aa6a" /> | References: [`NSAppearanceCustomization`](https://developer.apple.com/documentation/appkit/nsappearancecustomization) · [`NSApplication.appearance`](https://developer.apple.com/documentation/appkit/nsapplication/appearance) Release Notes: - Fixed the macOS window border and titlebar not matching the selected theme when the system appearance differed (for example, a dark theme under a light system theme). ([zed-industries#5049](zed-industries#5049)) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…-industries#61789) ### Objective PR zed-industries#58902 made native macOS window chrome follow the selected theme, but AppKit can synchronously invoke `viewDidChangeEffectiveAppearance` while the settings observer holds an `App` borrow. `handle.update` then fails with `RefCell already borrowed`, leaving `Window::appearance()` and its observers stale. ### Steps to reproduce 1. Set Zed's theme mode to Dark. 2. Set macOS Appearance to Light. 3. Change Zed's theme mode to System. 4. Notice that the window chrome switches to light, but Zed's UI remains dark. https://github.com/user-attachments/assets/f91962cc-76ba-4d8e-b587-2a2343f365ba ### Expectation Zed should switch to its configured light theme when returning to System mode. ### Solution Defer `Window::appearance_changed` to the foreground executor so the current `App` borrow finishes before refreshing the cached appearance and notifying observers. ### Testing - Added a regression test. ### Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [ ] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Release Notes: - N/A

…-industries#61789) PR zed-industries#58902 made native macOS window chrome follow the selected theme, but AppKit can synchronously invoke `viewDidChangeEffectiveAppearance` while the settings observer holds an `App` borrow. `handle.update` then fails with `RefCell already borrowed`, leaving `Window::appearance()` and its observers stale. 1. Set Zed's theme mode to Dark. 2. Set macOS Appearance to Light. 3. Change Zed's theme mode to System. 4. Notice that the window chrome switches to light, but Zed's UI remains dark. https://github.com/user-attachments/assets/f91962cc-76ba-4d8e-b587-2a2343f365ba Zed should switch to its configured light theme when returning to System mode. Defer `Window::appearance_changed` to the foreground executor so the current `App` borrow finishes before refreshing the cached appearance and notifying observers. - Added a regression test. - [x] I've reviewed my own diff for quality, security, and reliability - [ ] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Release Notes: - N/A (cherry picked from commit a11083f)

…58902) Closes zed-industries#5049. When the system is in light mode but Zed uses a dark theme, the macOS window chrome — the window border and the titlebar — is rendered light, leaving a pale, low-contrast edge that makes the window look washed out. Zed's own content renders correctly; the affected chrome is drawn by AppKit, not Zed. Why it happens: `NSWindow` conforms to `NSAppearanceCustomization`, so a window's appearance is inherited app → window → view and resolved through `effectiveAppearance` unless an explicit appearance is set. Zed never set one, so every window inherited the *system* appearance and AppKit drew the chrome for light mode regardless of the dark theme. The fix uses the override AppKit provides for exactly this: set `NSApplication.appearance` app-wide, so every window inherits it. VSCode (`window.systemColorTheme`) and JetBrains IDEs do the same. <img width="2600" height="1346" alt="after-light" src="https://github.com/user-attachments/assets/c31376af-8f51-4c36-a62f-55714f63b59c" /> ## GPUI - Add `App::set_window_appearance(Option<WindowAppearance>)`, the setter paired with the existing `App::window_appearance()` getter. `Some(_)` forces a light/dark appearance; `None` clears the override and follows the system again. - macOS sets `NSApplication.appearance` (`None` → `nil`); no-op on other platforms. - Demo: `cargo run -p gpui --example window_appearance`. ## Zed - An explicit light/dark theme (or a static theme) forces the matching chrome; `System` follows the OS. - Wired once at startup via a global settings observer, so every window — including the settings window — stays in sync. | Before | After | | --- | --- | | <img width="3630" height="1878" alt="before-light" src="https://github.com/user-attachments/assets/44c9ab66-c0cf-433a-93b0-17446b34a284" /> | <img width="3686" height="1832" alt="SCR-20260609-nzjk" src="https://github.com/user-attachments/assets/32b0412b-0913-4e68-acba-bf39dcb6aa6a" /> | References: [`NSAppearanceCustomization`](https://developer.apple.com/documentation/appkit/nsappearancecustomization) · [`NSApplication.appearance`](https://developer.apple.com/documentation/appkit/nsapplication/appearance) Release Notes: - Fixed the macOS window border and titlebar not matching the selected theme when the system appearance differed (for example, a dark theme under a light system theme). ([zed-industries#5049](zed-industries#5049)) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…-industries#61789) ### Objective PR zed-industries#58902 made native macOS window chrome follow the selected theme, but AppKit can synchronously invoke `viewDidChangeEffectiveAppearance` while the settings observer holds an `App` borrow. `handle.update` then fails with `RefCell already borrowed`, leaving `Window::appearance()` and its observers stale. ### Steps to reproduce 1. Set Zed's theme mode to Dark. 2. Set macOS Appearance to Light. 3. Change Zed's theme mode to System. 4. Notice that the window chrome switches to light, but Zed's UI remains dark. https://github.com/user-attachments/assets/f91962cc-76ba-4d8e-b587-2a2343f365ba ### Expectation Zed should switch to its configured light theme when returning to System mode. ### Solution Defer `Window::appearance_changed` to the foreground executor so the current `App` borrow finishes before refreshing the cached appearance and notifying observers. ### Testing - Added a regression test. ### Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [ ] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Release Notes: - N/A

cla-bot Bot added the cla-signed The user has signed the Contributor License Agreement label Jun 9, 2026

zed-community-bot Bot added the community champion Issues filed by our amazing community champions! 🫶 label Jun 9, 2026

huacnlee force-pushed the add-set-appearance branch from ae8e5ac to 5f56842 Compare June 9, 2026 08:00

Fix lint

fb1e219

ChristopherBiscardi added the platform:macOS Platform-specific feedback for macOS behaviors, features, design, etc label Jun 10, 2026

Veykril approved these changes Jul 15, 2026

View reviewed changes

Veykril self-assigned this Jul 15, 2026

Merge branch 'main' into add-set-appearance

f21acbb

Remove crates/gpui/examples/window_appearance.rs

66d95fb

Veykril approved these changes Jul 28, 2026

View reviewed changes

Veykril enabled auto-merge July 28, 2026 08:23

Veykril added this pull request to the merge queue Jul 28, 2026

Merged via the queue into zed-industries:main with commit 8e4e5a3 Jul 28, 2026
36 checks passed

huacnlee deleted the add-set-appearance branch July 28, 2026 09:08

errmayank mentioned this pull request Jul 28, 2026

gpui: Defer appearance change callback to avoid reentrant borrow #61789

Merged

5 tasks

github-actions Bot mentioned this pull request Aug 6, 2026

🎨 Zed GPUI Release Tracker gpui-archipelago/gpui-release-notes#3

Open

prabhic mentioned this pull request Aug 29, 2026

Randomly - Theme switch backed to Default #63305

Open

Navigation Menu

Uh oh!

Uh oh!

Match the macOS app appearance to the selected theme - #58902

Match the macOS app appearance to the selected theme#58902
Veykril merged 5 commits into
zed-industries:mainfrom
huacnlee:add-set-appearance

huacnlee commented Jun 9, 2026 •

edited

Loading

Uh oh!

huacnlee commented Jun 10, 2026 •

edited

Loading

Uh oh!

Veykril left a comment

Uh oh!

huacnlee commented Jul 28, 2026

Uh oh!

Veykril commented Jul 28, 2026

Uh oh!

huacnlee commented Jul 28, 2026

Uh oh!

Veykril left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Uh oh!

Conversation

huacnlee commented Jun 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

GPUI

Zed

Uh oh!

huacnlee commented Jun 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Veykril left a comment

Choose a reason for hiding this comment

Uh oh!

huacnlee commented Jul 28, 2026

Uh oh!

Veykril commented Jul 28, 2026

Uh oh!

huacnlee commented Jul 28, 2026

Uh oh!

Veykril left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

huacnlee commented Jun 9, 2026 •

edited

Loading

huacnlee commented Jun 10, 2026 •

edited

Loading