Fix dark styling of Copy Settings checkboxes on macOS (#3897)#3899
Merged
vogella merged 1 commit intoApr 17, 2026
Merged
Conversation
Contributor
On macOS Cocoa, setBackground/setForeground applied to a widget that is currently hidden is not retained once the widget is realized. The "Copy Settings" section of ChooseWorkspaceWithSettingsDialog is created with setVisible(false), so the theme-engine colors on its check buttons are dropped and the buttons paint with the default light system colors when the user expands the section on a dark theme. Re-apply the parent background/foreground to the check buttons when the section first becomes visible. Guarded with Util.isMac() since GTK and Windows retain the colors across realize and do not need this workaround. Fixes eclipse-platform#3897
vogella
force-pushed
the
fix/issue-3897-dark-copy-settings
branch
from
bdba619 to
c901990
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #3897 — macOS-only rendering regression in the "Copy Settings" section of the workspace selection dialog.
The section's
SWT.CHECKbuttons are created eagerly inside asectionClientcomposite that is hidden on first launch (ChooseWorkspaceWithSettingsDialog.java:151-153). The E4 CSS theme engine styles them at creation time, but on macOS Cocoa,setBackground/setForegroundcalls made on an unrealized (hidden) widget are not retained once the widget is realized. When the user expands the section the checkboxes paint with default native light colors — the bright rectangles visible in the screenshot attached to the issue.GTK and Windows retain widget color state across realize, so they render correctly without any workaround.
Fix
In
ChooseWorkspaceWithSettingsDialog.createSettingsControls, attach anSWT.Showlistener onsectionClientthat re-appliesworkArea.getBackground()/workArea.getForeground()to itsSWT.CHECKchildren when it first becomes visible. Guarded byUtil.isMac(); no-op on GTK and Windows. No public API change.Placing the workaround in the dialog (rather than in
IDEApplication.applyStylesRecursive) matches where the styling actually originates at runtime: when the dialog is opened fromOpenWorkspaceActioninside a running workbench, it is the CSS theme engine — notIDEApplication— that supplies the colors.Diagnostic process
Standalone SWT snippets isolated the Cocoa hidden-widget
setBackgroundquirk against thesetVisible(false)→ expand scenario. Fix was validated against the snippet; @Phillipus confirmed snippet behavior fixes the issue.Test plan