Allow to ignore explicitly defined disabled icons

[HeikoKlare]

This change allows to ignore explicitly defined disabled icons (as SWT provides a proper way to do it on-the-fly since 2025-06) and enabled that behavior by default.

This is an extract of:

• Configurably improve disabled icons appearance #3760

In that PR, no objections have been raised on always using the on-the-fly generation of disabled icons. I thus intend to merge this at the beginning of 4.41 development in case no objections are raised until then.

@HannesWell we had discussed the extraction of this rather non-controversial change offline. Maybe you want to have a quick a look.

Description

The algorithm for generating disabled icons on-the-fly has recently been enhanced. Most explicit disabled icons that have been embedded into bundles conform to what now can be generated on-the-fly. In addition, the algorithm is interchangeable, allowing custom stylings of disabled icons. However, when there are still bundles, such as extensions out of our control, that still explicitly define disabled icons, exchanging the algorithm for disabled icons will lead to inconsistent appearance as only the on-the-fly generated icons will adhere to that.

This change allows to ignore explicitly defined disabled icons, such that even if some bundles defined disabled icons, they will be ignored and on-the-fly generated disabled icons according to the selected algorithm will be used instead. An according preference that can be configured via the appearance tab is added.

How to test

The enhancement is configurable via preference, thus can be tested by enabling/disabling it:

As an example, this is what the main toolbar looks like with different configurations:

Existing

No pregenerated disabled icons

[github-actions]

Test Results

   867 files  ±0     867 suites  ±0   53m 42s ⏱️ - 8m 5s
 7 988 tests ±0   7 745 ✅ ±0  243 💤 ±0  0 ❌ ±0 
20 466 runs  ±0  19 811 ✅ ±0  655 💤 ±0  0 ❌ ±0 

Results for commit b8ed790. ± Comparison against base commit b58e3b4.

[HannesWell]

Thanks for this. I think this totally makes sense and helps to fade out explicit/dedicated disabled icons.

I just have one suggestions for their label/description.

[HannesWell]

What about labling these icons as explicit disabled icons or dedicated disabled icons?

Suggested change

	ViewsPreference_ignoreDisabledIcons = Ignore pre-generated disabled icons
	ViewsPreference_ignoreDisabledIcons_tooltip = When enabled ignores pre-generated disabled icons in favor of generating consistently styled disabled icons on the fly
	ViewsPreference_ignoreDisabledIcons = Ignore explicit disabled icons
	ViewsPreference_ignoreDisabledIcons_tooltip = When enabled ignores explicit disabled icons in favor of generating consistently styled disabled icons on the fly

But I'm not sure if explicit could be read with other meaning.

[nettozahler]

Regarding the suggestion: maybe we should clarify with a native English speaker if it must be named "explicitly disabled".

[HeikoKlare]

But I'm not sure if explicit could be read with other meaning.

That's why I tried to avoid the term in user-facing descriptions. I am sure I would not have understood the option when using that word if I was not involved in the development.

maybe we should clarify with a native English speaker if it must be named "explicitly disabled"

I think that's a good example, why we should avoid the term "explicit", because "explicitly disabled" would be incorrect in terms of semantics.

I have no really good proposal for an alternative either. Just though about something like "manually generated".

[laeubi]

For me a radio button style option would be more appropriate than a checkbox ... the current terms seem to technical for anyone to understand that is not familiar with the technical details.

Something similar to:

Generate disabled images (*) always ( ) only if not provided ( ) never

(where the last option would e.g. use the "native" disabled image appearance if we want to offer such option)

[HeikoKlare]

For me a radio button style option would be more appropriate than a checkbox ... the current terms seem to technical for anyone to understand that is not familiar with the technical details.

I agree that the description is currently too technical. That's something we need to solve by proper naming. A radio button alone will not solve that, in particular because there are only the two options "always generate" or "consider pre-generated/explicit/manually generated/...". "never" is not a possible option without starting a new feature for supporting that option.

Maybe just taking your proposed text for the radio buttons would be fine as something like:
Option: Always generate disabled icons on the fly
Description: When enabled, ignores any provided resources for disabled icons in favor of generating consistently styled disabled out of their enabled version icons on the fly