Configurably improve disabled icons appearance#3760
Open
HeikoKlare wants to merge 4 commits intoeclipse-platform:masterfrom
Open
Configurably improve disabled icons appearance#3760HeikoKlare wants to merge 4 commits intoeclipse-platform:masterfrom
HeikoKlare wants to merge 4 commits intoeclipse-platform:masterfrom
Conversation
Contributor
|
This pull request changes some projects for the first time in this development cycle. 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 patchFurther information are available in Common Build Issues - Missing version increments. |
Contributor
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 own 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.
This adds a preference which enables the use of desaturated disabled icons, which replaces the existing algorithm to create grayscaled version with an algorithm that generates a desaturated version.
HeikoKlare
force-pushed
the
configure-disabled-icons
branch
from
38603eb to
897d56a
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This consists of two subsequent changes:
The changes are put into separate commits and could be processed independently, but are mostly useful together, thus I put them into a single PR.
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 own 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.
This also adds a preference which enables the use of desaturated disabled icons, which replaces the existing algorithm to create grayscaled version with an algorithm that generates a desaturated version.
This alternative algorithm for disabled icons has been discussed and agreed on here:
How to test
Both enhancements are configurable via preferences, thus can be tested by enabling/disabling them:
As an example, this is what the main toolbar looks like with different configurations:
Existing
No pregenerated disabled icons
Desaturated disabled icons
Feedback
Feedback on the proposal is welcome as always. We can of course decide if we want to have both/either of these options enabled by default or not. Using the on-the-fly algorithm for calculating disabled icons by default makes sense to me to ensure a unified look and feel of them. Whether the alternative algorithm (desaturated vs. grayscaled) should be default may be more up to individual preference. But note that the new algorithm better aligns with common disablement visualizations used nowadays by Windows and GTK.
@HannesWell pinging you for feedback as we had already discussed about adding such options after we had implemented the new algorithm
@BeckerWdf pinging you for feedback as an expert on UX topics and as you were also involved into the discussion about the disabled icon look & feel back then