Use new SWT Display.setDarkThemePreferred() API for dark theme

[vogella]

Summary

Replace platform-specific dark theme processors (Win32, GTK, Cocoa) with the new cross-platform SWT API Display.setDarkThemePreferred(boolean) from eclipse-platform/eclipse.platform.swt#3184.

Changes

ThemeEngine (cross-platform)

• Calls display.setDarkThemePreferred(isDark) directly in setTheme(), signaling the OS dark mode preference whenever the CSS theme changes.
• Bumped SWT dependency to [3.134.0,4.0.0) for the new API.

IDEApplication (startup simplification)

• Replaced manual dark styling (hardcoded colors, SWT.Show listeners, recursive style application on splash/workspace dialog) with a single display.setDarkThemePreferred(true) call during early startup.
• Removed applyDarkStyles(), applyStylesRecursive(), and the isDark field.

Removed dark theme processor code from (bundles kept for later retirement):

• org.eclipse.e4.ui.swt.win32 — DarkThemeProcessor using internal OS.setTheme()
• org.eclipse.e4.ui.swt.gtk — DarkThemeProcessor using internal OS.setDarkThemePreferred()
• org.eclipse.e4.ui.workbench.renderers.swt.cocoa — CocoaDarkThemeProcessor using internal OS.setTheme()

Cleaned up MANIFEST.MF imports, fragment.xml extensions, and removed the now-unnecessary Require-Bundle on org.eclipse.e4.ui.css.swt.theme from the cocoa bundle.

Note

⚠️ Will not compile yet as SWT 3.134 is not available via p2 repos. The platform-specific bundles are intentionally kept (with empty fragments) for later retirement.

Fixes #3857

[github-actions]

Test Results

   852 files  ±0     852 suites  ±0   55m 19s ⏱️ - 2m 18s
 7 894 tests ±0   7 648 ✅  - 1  243 💤 ±0  3 ❌ +1 
20 184 runs  ±0  19 526 ✅  - 1  655 💤 ±0  3 ❌ +1 

For more details on these failures, see this check.

Results for commit 9799983. ± Comparison against base commit 357b87c.

♻️ This comment has been updated with latest results.

[eclipse-platform-bot]

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

bundles/org.eclipse.e4.ui.swt.gtk/META-INF/MANIFEST.MF
bundles/org.eclipse.e4.ui.swt.win32/META-INF/MANIFEST.MF
bundles/org.eclipse.e4.ui.workbench.renderers.swt.cocoa/META-INF/MANIFEST.MF

An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch.

Git patch

From ed7044275425e262fa4a238938edfaaeb04e3ad8 Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <platform-bot@eclipse.org>
Date: Wed, 8 Apr 2026 10:31:54 +0000
Subject: [PATCH] Version bump(s) for 4.40 stream


diff --git a/bundles/org.eclipse.e4.ui.swt.gtk/META-INF/MANIFEST.MF b/bundles/org.eclipse.e4.ui.swt.gtk/META-INF/MANIFEST.MF
index e6e792c72f..68fd639f3a 100644
--- a/bundles/org.eclipse.e4.ui.swt.gtk/META-INF/MANIFEST.MF
+++ b/bundles/org.eclipse.e4.ui.swt.gtk/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %fragmentName
 Bundle-SymbolicName: org.eclipse.e4.ui.swt.gtk;singleton:=true
-Bundle-Version: 1.2.200.qualifier
+Bundle-Version: 1.2.300.qualifier
 Fragment-Host: org.eclipse.e4.ui.css.swt.theme;bundle-version="0.10.0"
 Bundle-RequiredExecutionEnvironment: JavaSE-17
 Bundle-Localization: fragment-gtk
diff --git a/bundles/org.eclipse.e4.ui.swt.win32/META-INF/MANIFEST.MF b/bundles/org.eclipse.e4.ui.swt.win32/META-INF/MANIFEST.MF
index 9795fd9215..2a570b89b4 100644
--- a/bundles/org.eclipse.e4.ui.swt.win32/META-INF/MANIFEST.MF
+++ b/bundles/org.eclipse.e4.ui.swt.win32/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %fragmentName
 Bundle-SymbolicName: org.eclipse.e4.ui.swt.win32;singleton:=true
-Bundle-Version: 1.2.300.qualifier
+Bundle-Version: 1.2.400.qualifier
 Fragment-Host: org.eclipse.e4.ui.css.swt.theme;bundle-version="0.10.0"
 Bundle-RequiredExecutionEnvironment: JavaSE-17
 Bundle-Localization: fragment-win32
diff --git a/bundles/org.eclipse.e4.ui.workbench.renderers.swt.cocoa/META-INF/MANIFEST.MF b/bundles/org.eclipse.e4.ui.workbench.renderers.swt.cocoa/META-INF/MANIFEST.MF
index e9ca00ec3b..7c8b35b838 100644
--- a/bundles/org.eclipse.e4.ui.workbench.renderers.swt.cocoa/META-INF/MANIFEST.MF
+++ b/bundles/org.eclipse.e4.ui.workbench.renderers.swt.cocoa/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Eclipse-PlatformFilter: (osgi.ws=cocoa)
 Bundle-SymbolicName: org.eclipse.e4.ui.workbench.renderers.swt.cocoa;singleton:=true
-Bundle-Version: 0.14.600.qualifier
+Bundle-Version: 0.14.700.qualifier
 Bundle-Name: %fragmentName
 Bundle-Vendor: %providerName
 Fragment-Host: org.eclipse.e4.ui.workbench.renderers.swt;bundle-version="[0.10.0,1.0.0)"
-- 
2.53.0

Further information are available in Common Build Issues - Missing version increments.

[vogella]

This will already apply the default theme to the workspace launcher. But it seems that the launcher has some hard coded colors.

[merks]

It would seem better if you experimented locally in your workspace until it’s working well rather than in a public draft PR that generates yet more email about interim states of progress that are, in my opinion, best managed by you privately until it’s ready for prime time. I don’t think verification builds are providing value in this case, do they? Perhaps such builds only contribute to global warming and to email generation.

I’m tempted to ask about all the things I see being deleted, but it’s a draft so maybe pointless it’s a pointless question.

[vogella]

I’m tempted to ask about all the things I see being deleted, but it’s a draft so maybe pointless it’s a pointless question.

By using the dark API from SWT, we can delete the processors in platform.ui. The processors were doing it platform specific. Once this is in we can delete the fragment projects.

[merks]

So much mail. Please can this be reduced? Are the repeated builds and cascading notifications necessary? It just seems to be getting worse by the day. So many activities in parallel in public, driving endless builds and around the clock notifications.

Please, please reconsider your work patterns. Complete the design and testing before feeling the urge to create yet another draft on yet another topic in parallel to several others.

[vogella]

So much mail. Please can this be reduced? Are the repeated builds and cascading notifications necessary? It just seems to be getting worse by the day. So many activities in parallel in public, driving endless builds and around the clock notifications.

Please, please reconsider your work patterns. Complete the design and testing before feeling the urge to create yet another draft on yet another topic in parallel to several others.

Sure, I think you said the same in #3881 (comment).