Fixed a crash introduced in the previous version of this commit.

The original code called PartRenderingEngine.initializeStyling() before the workspace picker is shown. That method internally accesses InstanceScope preferences, which requires the workspace location to be set — causing an IllegalStateException.

The fix uses IThemeManager.getEngineForDisplay() + IThemeEngine.setTheme() directly instead (the same pattern used by BootstrapTheme3x). This activates the CSS theme engine without touching instance-scoped preferences, so it works safely before workspace selection.

Also fixed: OSGi service reference now released via ungetService() in a finally block, and the org.eclipse.e4.ui.workbench.swt bundle dependency (which exposed internal API) is removed.

Updated approach: dropped the CSS theme engine for the workspace dialog entirely.

The dark theme CSS uses symbolic color variables (#org-eclipse-ui-workbench-DARK_BACKGROUND etc.) that are resolved via ColorAndFontProviderImpl, which calls Workbench.getInstance().getThemeManager(). Since Workbench.getInstance() is null before the workbench starts, these colors can never resolve at this stage — so CSS styling of the pre-workspace dialog is not feasible.

New approach: if the configured theme ID contains "dark", directly set SWT colors on the dialog's widget tree using the literal RGB values from the dark theme CSS (#48484c background, #eeeeee foreground). Colors are allocated once on the shell and disposed via a DisposeListener.

First iteration:

Test Results

0 files   -    852  0 suites   - 852   0s ⏱️ - 57m 37s
0 tests  -  7 894  0 ✅  -  7 649  0 💤  - 243  0 ❌  - 2 
0 runs   - 20 184  0 ✅  - 19 527  0 💤  - 655  0 ❌  - 2 

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

♻️ This comment has been updated with latest results.

Getter better: