Creation of disabled icons

[Michael5601]

Currently, there are two methods for integrating disabled icons into Eclipse:

1. Pre-created Disabled Icons:
   Disabled icons are generated outside Eclipse and stored in the image repository. These icons are then referenced in the plugin.xml file using the disabledIcon attribute. For generating disabled icons, the [Image-Renderer](https://github.com/eclipse-platform/eclipse.platform.images/blob/master/org.eclipse.images.renderer/src/main/java/org/eclipse/images/renderer/RenderMojo.java) from the Eclipse Images repository can be used. This approach involves post-processing the icons with a third-party library after rasterization.

2. Runtime Conversion:
   If the disabledIcon attribute in the plugin.xml file is not set, the original (enabled) icon is automatically converted to a disabled icon at runtime using the org.eclipse.jface.resource.DerivedImageDescriptor. This involves loading the original icon and applying the org.eclipse.swt.graphics.Image.Image(Device, Image, int) constructor with the SWT.IMAGE_DISABLE flag. Here, too, the disabled effect is achieved through post-processing.

Questions about the Current Workflow

1. Since both methods for creating disabled icons rely on post-processing, why not streamline the process by using only the existing automatic method and removing all pre-created disabled icons from the repository?

2. Why is the implementation of the Image constructor different for GTK compared to other operating systems? Could we unify the constructor's behavior across all platforms to ensure consistent results?

I had planned to introduce an automatic method for generating disabled icons by pre-processing SVGs and then rasterizing them at runtime. This method would apply a filter to the SVG, ensuring that the icon appears disabled after rasterization. This approach would allow loading disabled icons directly via the DerivedImageDescriptor, eliminating the need for post-processing.

My solution works well and is likely much faster than the current automatic conversion. However, it introduces a problem: The visual appearance of disabled icons would differ across platforms. If calibrated to match Windows icons, it would appear inconsistent on GTK, and vice versa.

Given these inconsistencies, I will postpone implementing this solution until a unified approach for disabling icons is introduced to eclipse. Once there is a consistent method across platforms, I can fine-tune the filter to ensure it aligns with the style for disabled icons.

[akurtakov]

2. Why is the implementation of the Image constructor different for GTK compared to other operating systems? Could we unify the constructor's behavior across all platforms to ensure consistent results?

I'm not 100% sure what difference you look at exactly but that's most likely because GTK uses the OS image codecs and thus provides support for far more image types and better compatibility. E.g. if the "shared" codecs are used there will be no SVG rendering, issues with animated gifs and etc. problems that lead to that work. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=545032 for details.
Regarding SVG support https://bugs.eclipse.org/bugs/show_bug.cgi?id=545800 no one cared to add win/mac implementations.

[Michael5601]

The SVG support will be introduced by me, this is not something I expected to exist. Still I think the disabled icons that are created with my logic need to look the same as the existing disabled icons. This is not possible if different OS have different logic.
I only saw the different implementations and a colleague of mine @mkiesinger told me that they also look different on GTK. We will provide screenshots for that matter.

The code for the image constructor can be found here for GTK, cocoa and win32.

[akurtakov]

I mentioned the fact about SVG support on Gtk existing on one of the first calls and even asked you to see how/whether it fits in your work :) .
I see that I've been thinking in the wrong direction and the difference is not in which image codec (builtin or native) is used but rather in the disabled/gray flag support. As identified in another comment here the questions about this part specifically should go to @iloveeclipse and/or @trancexpress .

[Michael5601]

I mentioned the fact about SVG support on Gtk existing on one of the first calls and even asked you to see how/whether it fits in your work :) . I see that I've been thinking in the wrong direction and the difference is not in which image codec (builtin or native) is used but rather in the disabled/gray flag support. As identified in another comment here the questions about this part specifically should go to @iloveeclipse and/or @trancexpress .

Ah you meant native SVG support in this discussion today. I remember you told me that native SVG support exists in GTK but this was not important for me later in my work as I tried a non-native approach.

[akurtakov]

It really doesn't matter which codec is used - SWT on Linux supports SVG much like it supports PNG.

[trancexpress]

I mentioned the fact about SVG support on Gtk existing on one of the first calls and even asked you to see how/whether it fits in your work :) . I see that I've been thinking in the wrong direction and the difference is not in which image codec (builtin or native) is used but rather in the disabled/gray flag support. As identified in another comment here the questions about this part specifically should go to @iloveeclipse and/or @trancexpress .

Do you mean the difference introduced here? https://bugs.eclipse.org/bugs/show_bug.cgi?id=575069

[akurtakov]

Would you show the differences between windows/linux? Also please point to exact difference in code so I don't end up thinking of smth else than you.

[BeckerWdf]

Would be great to also see the visual difference on the different platforms

[mkiesinger]

I will provide a Snippet showing the differences in a separate issue soon.

The algorithms for Windows and MacOS implementations map every pixel
r² + g² + b² < 98304 -> SWT.COLOR_WIDGET_NORMAL_SHADOW
else -> SWT.COLOR_WIDGET_BACKGROUND (= invisible)

The GTK implementation halfes the pixels red, green and blue values, retaining the pixels color but making it darker.

[laeubi]

Since both methods for creating disabled icons rely on post-processing, why not streamline the process by using only the existing automatic method and removing all pre-created disabled icons from the repository?

Because you can only get "something that looks disabled according to what the os offers" but usually one maybe wants to have more control e.g. getting a nicer look&feel.

Lets assume you have a checkbox that is a black bordered box with white background, if you "disable" that image by usually making it gray, it will look exactly the same, so you cant distinguish an unchecked box from a disabled one. So in this case one might decide to give the box a light-gray border, or a different background color as a disabled image.

[mkiesinger]

I am currently working on the icon-disabling mechanism to enhance the look for icons with modern flat designs. The current algorithm maps colors to only 2 gray tones, where one is the background color, making some icons invisible altogether. Ill provide a snippet with a proposition of new disabling algorithms in a separate issue.

To answer question 2:
All implementations worked like this until 3 years ago, where the GTK implementation was changed to make it look more like standard GTK.

This change adjusts the implementation of SWT.IMAGE_DISABLE under GTK+,
so that the resulting disabled images are in-line with the GTK+ disabled
look & feel. GTK+ disabled icons retain more detail and color, while
also appearing grayed out.

Bug 575069 - [GTK] Disabled toolbar/button/menu images have poor quality · eclipse-platform/eclipse.platform.swt@2fa3c28

[BeckerWdf]

2. If the disabledIcon attribute in the plugin.xml file is not set, the original (enabled) icon is automatically converted to a disabled icon at runtime using the org.eclipse.jface.resource.DerivedImageDescriptor.

I didn't know this. Cool.

[Michael5601]

I want to correct myself as not every disabled icon is created by calling org.eclipse.jface.resource.DerivedImageDescriptor as soon as the disabledIcon attribute is deleted. There are some places where the Image-constructor that is also used by org.eclipse.jface.resource.DerivedImageDescriptor is called directly. On example can be seen in org.eclipse.ui.internal.dialogs.WorkbenchEditorsDialog.Adapter.getImage() at line 729. I think the generation is still automatic the most time as soon as the attribute is deleted.

I experienced problems deleting the disabled icons in org.eclipse.ui as some of the d paths for example dtool are hardcoded in org.eclipse.ui.internal.WorkbenchImages.

[Michael5601]

The disabled icons automatically generated by the current org.eclipse.swt.graphics.Image.Image(Device, Image, int) constructor on windows are pretty bad.

These are the results that I get:

Compared to the pre-designed icon solution: