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

[vogella]

Dark mode for native components (title bars, scrollbars, native dialogs) is now handled by the cross-platform SWT API Display.setDarkThemePreferred(boolean), which the ThemeEngine calls whenever the CSS theme changes.
This makes the platform-specific dark theme processors for GTK, Win32 and Cocoa obsolete, so they are removed.
The GTK and Win32 fragments only existed to host their processor and are deleted together with their entries in the org.eclipse.e4.rcp feature; the Cocoa fragment is kept because it still provides other processors.
IDEApplication no longer applies manual dark styling (hardcoded colors, SWT.Show listeners, recursive styling) and instead relies on the early Display.setDarkThemePreferred(true) call for the workspace selection dialog.

Fixes #3857

[github-actions]

Test Results

   852 files  ±0     852 suites  ±0   49m 36s ⏱️ + 7m 19s
 8 058 tests ±0   7 815 ✅ ±0  243 💤 ±0  0 ❌ ±0 
20 076 runs  +5  19 422 ✅ +5  654 💤 ±0  0 ❌ ±0 

Results for commit 3932688. ± Comparison against base commit ad6bfe7.

♻️ 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.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 ee41ce6ba0ffcfe031a063d46340353b85e4055d Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <platform-bot@eclipse.org>
Date: Wed, 17 Jun 2026 18:50:26 +0000
Subject: [PATCH] Version bump(s) for 4.41 stream


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.54.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).