Description
Currently, the Eclipse IDE and RCP applications handle native dark mode (e.g., dark title bars, scrollbars, and native dialogs) through a fragmented set of platform-specific processors. These processors often rely on reflection, internal access, or fragile hooks into the OS.
Examples of current platform-specific implementations:
org.eclipse.e4.ui.swt.internal.cocoa.CocoaDarkThemeProcessororg.eclipse.e4.ui.swt.internal.win32.DarkThemeProcessororg.eclipse.e4.ui.swt.internal.gtk.DarkThemeProcessor
These are often invoked late in the application lifecycle or require complex setup (like the CSS engine) to be fully effective.
The Problem
One specific area of difficulty is the early startup phase. Elements like the Splash screen and the Workspace Selection Dialog (ChooseWorkspaceDialog) are created before the full E4 workbench and CSS engine are initialized. To style these with the user's "default theme" preference (e.g., a dark theme), we currently have to manually apply styles and listen for shell creation in IDEApplication.
Even then, native components like the DirectoryDialog (Browse button in the workspace launcher) do not respect these styles because the OS is not aware that the application "prefers" a dark look.
Proposed Improvement
We propose the introduction of a cross-platform API in SWT (e.g., Display.setDarkThemePreferred(boolean)) that signals the dark mode preference directly to the OS.
Resulting Simplifications:
- Startup UI: In
IDEApplication, we could simply call display.setDarkThemePreferred(true) based on the saved default theme preference. This would immediately make the Splash screen and the Workspace Launcher (including its native DirectoryDialog) look correct without manual CSS application or complex listeners.
- Native Consistency: Title bars on Windows, macOS, and Linux would automatically switch to their immersive dark variants.
- Code Cleanup: We can eventually phase out the fragile, platform-specific processors in
org.eclipse.e4.ui.workbench.swt and related bundles, replacing them with a single, supported SWT call.
Benefits
- Better UX: A consistent dark experience from the first frame.
- Maintainability: Reduced reliance on internal platform-specific hacks.
- Standards-based: Leverages native OS capabilities (DWM on Windows, NSAppearance on macOS, GTK settings on Linux).
Description
Currently, the Eclipse IDE and RCP applications handle native dark mode (e.g., dark title bars, scrollbars, and native dialogs) through a fragmented set of platform-specific processors. These processors often rely on reflection, internal access, or fragile hooks into the OS.
Examples of current platform-specific implementations:
org.eclipse.e4.ui.swt.internal.cocoa.CocoaDarkThemeProcessororg.eclipse.e4.ui.swt.internal.win32.DarkThemeProcessororg.eclipse.e4.ui.swt.internal.gtk.DarkThemeProcessorThese are often invoked late in the application lifecycle or require complex setup (like the CSS engine) to be fully effective.
The Problem
One specific area of difficulty is the early startup phase. Elements like the Splash screen and the Workspace Selection Dialog (
ChooseWorkspaceDialog) are created before the full E4 workbench and CSS engine are initialized. To style these with the user's "default theme" preference (e.g., a dark theme), we currently have to manually apply styles and listen for shell creation inIDEApplication.Even then, native components like the
DirectoryDialog(Browse button in the workspace launcher) do not respect these styles because the OS is not aware that the application "prefers" a dark look.Proposed Improvement
We propose the introduction of a cross-platform API in SWT (e.g.,
Display.setDarkThemePreferred(boolean)) that signals the dark mode preference directly to the OS.Resulting Simplifications:
IDEApplication, we could simply calldisplay.setDarkThemePreferred(true)based on the saved default theme preference. This would immediately make the Splash screen and the Workspace Launcher (including its native DirectoryDialog) look correct without manual CSS application or complex listeners.org.eclipse.e4.ui.workbench.swtand related bundles, replacing them with a single, supported SWT call.Benefits