-
Notifications
You must be signed in to change notification settings - Fork 9k
Fix tab contrast colors when in high contrast #18109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This makes the tabs still adhere to the WT theme. However, that doesn't necessarily guarantee that the colors will be in high contrast.
DiscussionThe OS allows users to set a contrast theme: This is achieved by using the following XAML resource keys: However, Windows Terminal offers a lot of built-in customizability, namely through color schemes and theming. In fact, the default theme is: {
"name": "dark",
"window": {
"applicationTheme": "dark"
},
"tab": {
"background": "terminalBackground",
"unfocusedBackground": "#00000000"
},
"tabRow": {
"unfocusedBackground": "#333333FF"
}
},So, the question is, how do we balance the two? What I've done here is ignore the OS theme, basically. The main one I'm looking at in the default theme is CC @zadjii-msft as the father of WT Theming |
Discussed as a team. The current solution works just fine. We'll keep an eye on the tab row and other reported High Contrast issues for the future. |
If we colored a tab, then switched to another tab, there's a bug that the unselected tab loses its color. This was introduced in PR #18109. This PR fixes that by actually applying the selected color to the tab (whoops). Additionally, I removed setting the "TabViewItemHeaderCloseButtonBackground" resource because it looked weird (see comment in PR). Closes #18226
## Summary of the Pull Request Turns out that the `"TabViewItemHeaderBackground"` resource should be set to the _selected_ color instead of the _deselected_ color. In 1.22, (pre-#18109) we actually didn't set this resource. But we do actually need it for high contrast mode! (verified) ## Validation Steps Performed ✅ High contrast mode looks right ✅ "Snazzy" theme from bug report looks right ## PR Checklist Closes #19343
Turns out that the `"TabViewItemHeaderBackground"` resource should be set to the _selected_ color instead of the _deselected_ color. In 1.22, (pre-#18109) we actually didn't set this resource. But we do actually need it for high contrast mode! (verified) ✅ High contrast mode looks right ✅ "Snazzy" theme from bug report looks right Closes #19343 (cherry picked from commit b62cad6) Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgfrGvM Service-Version: 1.23
## Summary of the Pull Request Turns out that the `"TabViewItemHeaderBackground"` resource should be set to the _selected_ color instead of the _deselected_ color. In 1.22, (pre-#18109) we actually didn't set this resource. But we do actually need it for high contrast mode! (verified) ## Validation Steps Performed ✅ High contrast mode looks right ✅ "Snazzy" theme from bug report looks right ## PR Checklist Closes #19343 (cherry picked from commit b62cad6) Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgfrGvI Service-Version: 1.24









Summary of the Pull Request
Originally, the XAML resources were being applied on the TabView's ResourceDictionary directly. However, high contrast mode has a few weird scenarios as it basically reduces the color palette to just a few colors to ensure high contrast. This PR now stores the resources onto the ThemeDictionaries so that we have more control over the colors used.
References and Relevant Issues
Closes #17913
Closes #13067 (fixed by 5be0056)
Validation Steps Performed
Compared the following scenarios to WinUI 2 gallery's TabView when in High Contrast mode:
✅ (Un)selected tab
✅ hover over x of (un)selected tab
✅ hover over unselected tab