Remove redundant platform-specific dark theme processors

[vogella]

The cross-platform SWT API Display.setDarkThemePreferred(boolean) already drives native dark mode (title bars, scrollbars, native dialogs), and the ThemeEngine calls it whenever the CSS theme changes.
That makes the platform-specific dark theme processors for GTK, Win32 and Cocoa redundant, so they are removed along with the fragile internal/reflection-based hooks they relied on.
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.
The early Display.setDarkThemePreferred(true) call and the manual styling of the workspace selection dialog in IDEApplication are intentionally left in place, because the CSS engine is not yet running at that point in startup.

Fixes #3857

[github-actions]

Test Results

   855 files  ±0     855 suites  ±0   51m 44s ⏱️ -27s
 8 072 tests ±0   7 829 ✅ ±0  243 💤 ±0  0 ❌ ±0 
20 118 runs  ±0  19 464 ✅ ±0  654 💤 ±0  0 ❌ ±0 

Results for commit d0994ee. ± Comparison against base commit 12912e3.

♻️ 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).

[vogella]

Testing this now in a custom aggregator build.

[vogella]

Tested on Linux and Windows (I have no access to Mac) in an custom aggregator build and styling still works and OS components, like scrollbars in Windows are still styled.

@HannesWell any concerns from the releng side? AFAICS these fragments are not part of a pom.xml and I removed the reference to them in the feature.xml

I plan to merge early next week if I do not hear concerns.

[HannesWell]

It's nice to have the build and platform a bit simpler with this. Thanks for that.
And considering the theme earlier is also good. 👍🏽

any concerns from the releng side? AFAICS these fragments are not part of a pom.xml and I removed the reference to them in the feature.xml

From RelEng POV this change should be fine. I didn't find anymore relevant references.

I just see that in SWT there seem to be code, that could be obsolete now:
https://github.com/eclipse-platform/eclipse.platform.swt/blob/cb31ff97da4f842ad7c65af7dff65460178880c6/bundles/org.eclipse.swt/Eclipse%20SWT%20PI/gtk/org/eclipse/swt/internal/gtk/OS.java#L2030-L2041