Add SVGs to org.eclipse.debug.ui

[Michael5601]

This PR adds all SVGs of org.eclipse.debug.ui and changes related paths except for the following as these are not available as SVG yet:

obj16:
launchConfiguration.svg

ovr16:
quickaccess_debug
quickaccess_profile
quickaccess_run

wizban:
adddir_wiz
addsrcloc_wiz
debug_wiz
editdir_wiz
edtsrclkup_wiz
export_brkpts_wizban
export_config_wizban
import_brkpts_wizban
import_config_wizban
profile_wiz
run_wiz

The changes can be seen in the toolbar of the debug perspective:

Default (PNG):

Updated (SVG):

We should add this change in M1 so we can properly test the SVG feature that was introduced in this PR with a bundle that contains SVGs.

[github-actions]

Test Results

 1 598 files  ±0   1 598 suites  ±0   1h 28m 37s ⏱️ - 1m 53s
 4 173 tests ±0   4 150 ✅ ±0   23 💤 ±0  0 ❌ ±0 
11 998 runs  ±0  11 832 ✅ ±0  166 💤 ±0  0 ❌ ±0 

Results for commit 7f33b86. ± Comparison against base commit 9e339b2.

♻️ This comment has been updated with latest results.

[HeikoKlare]

There seems to be an issue with how SVGs are generated for a specific zoom since I face the same issue as mentioned in eclipse-platform/eclipse.platform.ui#2643 (review) for icons from Platform UI now also with the ones exchanged with SVGs in this PR:

How to reproduce:

• Two monitors, primary at 100% and secondary at 175%, monitor-specific scaling enabled
• Move window to secondary monitor

[HeikoKlare]

You can ignore my previous comment. I found the issue for the wrongly scaled SVGs: the Image implementation was erroneous. If the data for an image at the zoom level of the file (usually 100) was already loaded, this data is scaled instead of loading the file in proper zoom anew (as required for SVGs). That's easy to fix with a PR I provided today, so I added a fix that PR:

• Allow to test for loading image at zoom and fix faulty Win32 image load eclipse.platform.swt#1987

Then with the same scenario as above it looks like this:

[HannesWell]

When we merge this, we should also have eclipse-platform/eclipse.platform.swt#1936 available, shouldn't we? Otherwise I expect the disabled SVGs to not look good.

[HannesWell]

When we merge this, we should also have eclipse-platform/eclipse.platform.swt#1936 available, shouldn't we? Otherwise I expect the disabled SVGs to not look good.

On the other hand I recall a (private) discussion with Heiko where he said, that the current state of that SWT PR is not yet fully ready and needs further refinement.

[Michael5601]

When we merge this, we should also have eclipse-platform/eclipse.platform.swt#1936 available, shouldn't we? Otherwise I expect the disabled SVGs to not look good.

The disabled icons are not affected by this. I only changed the paths of the normal icons to SVG and added the SVGs. I ignored all disabled icons so they will look exactly as before.

[HannesWell]

Thank you for this work! The change looks good and it's great to finally have the first SVG icons in real use!

Altough this contributon is much larger than 1000 LOC (which usually requires an IP-review), this is fine because all the SVG files originate from https://github.com/eclipse-platform/eclipse.platform.images.
Eventually I think all SVG files that have been moved into the using plugin should be removed from that repo to avoid maintaining it at two different places.

As soon as eclipse-platform/eclipse.platform.ui#2593 is submitted, this can be submitted too.

[HannesWell]

As the doc of hoverIcon says:

a relative path of an icon used to visually represent the action in its context when the mouse pointer is over the action.
If omitted, the normal icon will be used. The path is relative to the location of the plugin.xml file of the contributing plug-in.

I think we could just remove the hoverIcon attribute with a value equal to the icon attribute.
But since the current state doesn't hurt, I think this can be done in a follow-up.

[BeckerWdf]

maybe a stupid question: Do I need to activate the rendering of the SVG icons somehow on macOS?

[Michael5601]

maybe a stupid question: Do I need to activate the rendering of the SVG icons somehow on macOS?

No you do not need to activate something, every icon will automatically be rendered using SVGs but to see an improvement it is important to use the right autoScaling mode. On Windows the default autoScaling mode is set to quarter since the new multi-monitor UI scaling. WIthout the right mode an SVGs will be rendered in the next bigger available size (e.g. 200%) and then downscaled to the correct size (e.g. 125%).

I did not test it yet on MacOs but can you try adding the following line in your eclipse.ini:
-Dswt.autoScale=quarter

Please note that for now only the bundle org.eclipse.debug.ui bundle contains SVGs, so you need to switch to the debug-perspective to see a difference.

[BeckerWdf]

I did not test it yet on MacOs but can you try adding the following line in your eclipse.ini:
-Dswt.autoScale=quarter

I did this (added to the launch config not the ini file) but I could not see a difference on my macOS retina display. Is the scaling on macOS so good?

[Michael5601]

I did not test it yet on MacOs but can you try adding the following line in your eclipse.ini:
-Dswt.autoScale=quarter

I did this (added to the launch config not the ini file) but I could not see a difference on my macOS retina display. Is the scaling on macOS so good?

I think so. In the discussions I read, before I implemented this feature, it seemed like people using macOS had less problems with scaling icons. The new smooth scaling shouldn't be activated for macOS as far as I know. Can you please try also adding -Dswt.autoScale.method=nearest and thus deactivating smooth scaling?

[HeikoKlare]

MacOS does only support 100% and 200% scaling. Since we had already provided the rasterized versions for those two scale values, you will not see any difference on MacOS. They will be equally sharp or blurry (like everything on MacOS) as they were before.
Using quarter or any other auto-scale setting will make no difference on MacOS since are not such "quarter" values for the scaling.