Automatically enable AdjustIndistinguishableColors if High Contrast mode enabled #17346
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| } | ||
|
|
||
| bool isCurrentlyHighContrast = []() { | ||
| HIGHCONTRAST hc = { 0 }; |
Check failure
Code scanning / check-spelling
Unrecognized Spelling Error
|
|
||
| bool isCurrentlyHighContrast = []() { | ||
| HIGHCONTRAST hc = { 0 }; | ||
| hc.cbSize = sizeof(HIGHCONTRAST); |
Check failure
Code scanning / check-spelling
Unrecognized Spelling Error
|
For the record, |
@check-spelling-bot Report🔴 Please reviewSee the 📂 files view, the 📜action log, or 📝 job summary for details. Unrecognized words (1)HIGHCONTRAST Previously acknowledged words that are now absentCRLFs Redir wcsicmp 🫥To accept these unrecognized words as correct and remove the previously acknowledged and now absent words, you could run the following commands... in a clone of the [email protected]:microsoft/terminal.git repository curl -s -S -L 'https://raw.githubusercontent.com/check-spelling/check-spelling/v0.0.22/apply.pl' |
perl - 'https://github.com/microsoft/terminal/actions/runs/9325600191/attempts/1'Available 📚 dictionaries could cover words (expected and unrecognized) not in the 📘 dictionaryThis includes both expected items (2212) from .github/actions/spelling/expect/04cdb9b77d6827c0202f51acd4205b017015bfff.txt
Consider adding them (in with:
extra_dictionaries:
cspell:cpp/src/lang-jargon.txt
cspell:swift/src/swift.txt
cspell:gaming-terms/dict/gaming-terms.txt
cspell:monkeyc/src/monkeyc_keywords.txt
cspell:cryptocurrencies/cryptocurrencies.txtTo stop checking additional dictionaries, add (in check_extra_dictionaries: ''Errors (1)See the 📂 files view, the 📜action log, or 📝 job summary for details.
See ❌ Event descriptions for more information. ✏️ Contributor please read thisBy default the command suggestion will generate a file named based on your commit. That's generally ok as long as you add the file to your commit. Someone can reorganize it later. If the listed items are:
See the 🔬 You can test your commits without appending to a PR by creating a new branch with that extra change and pushing it to your fork. The check-spelling action will run in response to your push -- it doesn't require an open pull request. By using such a branch, you can limit the number of typos your peers see you make. 😉 If the flagged items are 🤯 false positivesIf items relate to a ...
|
Why is this a draft?Looks like the feature flag stuff decided to fail on me halfway through the implementation (it wasn't failing when I started working on it, and I haven't pulled any new changes). I'm thinking this might be because Build Output |
Hmm that's odd. Your PR doesn't touch anything like that. You may have to just do a good 'ol |
|
|
||
| if (updateSettings) | ||
| { | ||
| UpdateSettingsRequested.raise(_currentHighContrastModeState); |
There was a problem hiding this comment.
Why does the IslandWindow of all things need to remember whether we were in dark mode or not? Also, why does it result in ReloadSettings when none of the settings changed? An alternative idea:
- Add a
bool CascadiaSettings::ReloadingSystemConfig()function (or similar).- It reads the dark-mode-ness and the high-contrast-ness of the OS.
- It caches the 2 results inside (for instance)
GlobalAppSettings. - If checks if either of 2 have changed and returns
trueif they did,falseotherwise. - The cached values replace any use of
IsSystemInDarkTheme()inside the settings code (currently in 2 locations).
- Add an alternative to
ReloadSettings(), e.g.ReloadingSystemConfigRelatedSettings()(lol) and call that inWindowEmperor::_windowRequestUpdateSettings(). - In
ReloadingSystemConfigRelatedSettings()call_settings.ReloadingSystemConfig()and check if it returnedtrue. If it did: Raise aSettingsChangedevent, just like we do inReloadSettings.
|
I think @PankajBhojwani has some research on this with JTippet |
|
I wonder if we also want to increase the delta e threshold we use when we detect high contrast mode! That was what we discussed with Jeffrey Tippet (3 years ago at this point wow), his response was along the lines of "that makes sense, though know that this isn't the way win32 apps work". I think how color nudging should work with HC is something that likely needs more discussion/potentially a spec, but automatically turning on the feature when in HC mode makes sense as a start. |
|
Ah, sounds like you're talking about this. 😏 |
Summary of the Pull Request
If High Contrast mode is enabled in the OS settings, we now automatically enable
adjustIndistinguishableColors. To accomplish this, a newAutomaticAlwaysandAutomaticIndexedvalue is added toadjustIndistinguishableColors. When these are chosen, color nudging doesn't occur in regular contrast sessions, but we interpret the value asAlwaysandIndexedrespectively.The new default value is
AutomaticIndexed. Meaning that regular contrast sessions will see no difference in behavior. However, if they switch to high contrast mode, Windows Terminal will interpret the value asIndexedat runtime. This was chosen becauseAlwaysis more performance intensive.References and Relevant Issues
#12999
Detailed Description of the Pull Request / Additional comments
The order of events is as follows:
IslandWindowreceives aWM_SETTINGCHANGEevent where we check if High Contrast mode was enabledUpdateSettingsRequestedwith abool HighContrastparameterCascadiaSettingsas astatic bool HighContrastTerminalPaneContentgoes through theUpdateSettingsprocess. However, now we stuff theCascadiaSettings::HighContrastModevalue into theTerminalSettings, then tell the control to update its settingsHighContrastModein theTerminalobject we're updatingTerminalupdates its appearance, we evaluateAutomaticIndexedandAutomaticAlwaysas non-automatic values, then update the render settings appropriately.Validation Steps Performed
Individual components have been tested, however, including...
CascadiaSettingsadjustIndistinguishableColorsAutomaticXvalues asXat runtime