Detect the desired size from the path or Query parameters.

[laeubi]

Currently we have the problem that I want to replace some icons with a SVG variant. Currently Icons can be organized in folders like /icons/16x16/search.png, /icons/32x32/search.png and so on for high resolution support. Currently if one want to replace such structure with SVG it is required to scale down the SVG to 16x16 pixel document size as otherwise they get rendered at there native size (what usually is much larger).

As it is not really desirable to restrict the size of the SVG design for technical reasons, JFace now can detect two cases:

1. the SVG is places in a folder with "classic" folder layout the size is extracted and passed down as a hint for dynamic sizable icons 2) one can additionally add a query parameter, e.g. if I have an icon like /icons/obj16/search.svg and I have two places where I want to use it one for a toolbar (16x16) and once for a Wizard Images (usually 128x128) I can use the url
   bundle:/example.id/icons/obj16/search.svg?size=16x16 and bundle:/example.id/icons/obj16/search.svg?size=128x128 to accomplish this task without the need to even store two SVGs

[github-actions]

Test Results

 2 667 files   -   345   2 667 suites   - 345   1h 38m 15s ⏱️ - 36m 22s
 8 255 tests +   13   8 004 ✅ +   11  249 💤 +  1  2 ❌ +1 
21 931 runs   - 1 715  21 348 ✅  - 1 506  581 💤  - 210  2 ❌ +1 

For more details on these failures, see this check.

Results for commit cd2c434. ± Comparison against base commit 50c2ad6.

This pull request skips 1 test.

UiTestSuite ApiTestSuite WorkbenchPluginTest ‑ testGetImageRegistryFromAdditionalDisplay

♻️ 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:

tests/org.eclipse.jface.tests/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 296a7771225554063f0aa4e723797297fda4a418 Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <platform-bot@eclipse.org>
Date: Tue, 9 Dec 2025 07:01:35 +0000
Subject: [PATCH] Version bump(s) for 4.39 stream


diff --git a/tests/org.eclipse.jface.tests/META-INF/MANIFEST.MF b/tests/org.eclipse.jface.tests/META-INF/MANIFEST.MF
index b8dc172d3e..8cadbfa2c6 100644
--- a/tests/org.eclipse.jface.tests/META-INF/MANIFEST.MF
+++ b/tests/org.eclipse.jface.tests/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %Bundle-Name
 Bundle-SymbolicName: org.eclipse.jface.tests
-Bundle-Version: 1.4.1100.qualifier
+Bundle-Version: 1.4.1200.qualifier
 Automatic-Module-Name: org.eclipse.jface.tests
 Bundle-RequiredExecutionEnvironment: JavaSE-17
 Require-Bundle: org.junit;bundle-version="4.12.0",
-- 
2.52.0

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

[laeubi]

Some test are failing here because Equinox is not parsing query strings correctly, I tried to address this here:

• Query String is not correctly parsed for bundle resource URLs eclipse-equinox/equinox#1217

[HeikoKlare]

The proposal looks fine for me now. I approve despite the currently failing tests since I will be on vacation soon and just want to document my opinion before that. I know that you will take of the tests and not merge before they run fine :-)

The SWT version constraint obviously makes sense because of the access to SWT internals which can change in any future release. That means we now have to update that dependency (bumping the upper bound if appropriate) for every new SWT release, right?

[laeubi]

That means we now have to update that dependency (bumping the upper bound if appropriate) for every new SWT release, right?

At least unless we have an official (stable) API for that.