UI is broken in system high contrast mode #7416

@jtippet commented on GitHub (Apr 15, 2020):

@zadjii-msft - I just stopped by the Terminal github project to send you guys an email to ask you to update to the latest MUX, so I can start contributing some PRs to smooth out Terminal's HC experience. I promise mimi8999 is not in cahoots with me, and this issue getting filed today is a total coincidence ;)

XAML has a global "I understand high contrast" flag named ApplicationHighContrastAdjustment. For Terminal, it's currently in HC-ignorant mode, which means MUX is more aggressive about ignoring your colors and automatically backplating text. This is not wrong, but it will make it difficult to reach perfect beauty. Beyond updating MUX, the next best thing you can do is toggle that flag, then fix the issues that it was hiding (invisible dialog box buttons, menu text, wrong titlebar color, etc.)

I'm happy to contribute wherever you can use help -- the whole reason I fixed MUX's TabView was so I could subsequently make my terminals not ugly.

@jtippet commented on GitHub (Apr 15, 2020): @zadjii-msft - I just stopped by the Terminal github project to send you guys an email to ask you to update to the latest MUX, so I can start contributing some PRs to smooth out Terminal's HC experience. I promise mimi8999 is not in cahoots with me, and this issue getting filed today is a total coincidence ;) XAML has a global "I understand high contrast" flag named ApplicationHighContrastAdjustment. For Terminal, it's currently in HC-ignorant mode, which means MUX is more aggressive about ignoring your colors and automatically backplating text. This is not wrong, but it will make it difficult to reach perfect beauty. Beyond updating MUX, the next best thing you can do is toggle that flag, then fix the issues that it was hiding (invisible dialog box buttons, menu text, wrong titlebar color, etc.) I'm happy to contribute wherever you can use help -- the whole reason I fixed MUX's TabView was so I could subsequently make my terminals not ugly.

claunia commented

@mimi89999 commented on GitHub (Apr 15, 2020):

@jtippet Were you able to build Terminal with latest MUX release? I wasn't.

@mimi89999 commented on GitHub (Apr 15, 2020): @jtippet Were you able to build Terminal with latest MUX release? I wasn't.

claunia commented

@jtippet commented on GitHub (Apr 15, 2020):

I didn't attempt that. I've only prototyped the other half - cleaning up button labels and menu text.

@jtippet commented on GitHub (Apr 15, 2020): I didn't attempt that. I've only prototyped the other half - cleaning up button labels and menu text.

claunia commented

@DHowett-MSFT commented on GitHub (Apr 17, 2020):

Triaging this for 1.x. If WinUI 2.4 lands before that, we may get it as part of a dependency updating pass.

@DHowett-MSFT commented on GitHub (Apr 17, 2020): Triaging this for 1.x. If WinUI 2.4 lands before that, we may get it as part of a dependency updating pass.

claunia commented

@WSLUser commented on GitHub (Apr 21, 2020):

Since I was looking into bumping deps, I did try updating to the preview release (we are actually on a 2.2. preview so going to 2.4 preview seems acceptable) but ran into problems attempting to build. I can update the other stuff but while debug mode is fine, the release mode has an issue compiling conpty in preview mode of VS 2019 and a problem finding the generated .lib in stable. Not sure what exactly is at play but my fork is available to test with. Also, you need to statically assign paths for instead of using wildcards in the build process. VS2019 won't accept the wildcards (building Terminal becomes even worse without letting VS statically assign the build paths).

@WSLUser commented on GitHub (Apr 21, 2020): Since I was looking into bumping deps, I did try updating to the preview release (we are actually on a 2.2. preview so going to 2.4 preview seems acceptable) but ran into problems attempting to build. I can update the other stuff but while debug mode is fine, the release mode has an issue compiling conpty in preview mode of VS 2019 and a problem finding the generated .lib in stable. Not sure what exactly is at play but my fork is available to test with. Also, you need to statically assign paths for instead of using wildcards in the build process. VS2019 won't accept the wildcards (building Terminal becomes even worse without letting VS statically assign the build paths).

claunia commented

@DHowett-MSFT commented on GitHub (Apr 21, 2020):

Thanks for looking into this! I’m a bit concerned. We are using 2.3, for what it’s worth, and even though it says “prerelease” it’s definitely the full retail payload. There’s a depressing reason for that... but in short, the “prerelease” builds put their DLLs inside our package, and the retail ones do not, and we need that copy of their DLL.

Which version of VS2019 are you seeing this with? The team has been building on 2019 since it came out, and hasn’t seen any trouble with the wildcards.

@DHowett-MSFT commented on GitHub (Apr 21, 2020): Thanks for looking into this! I’m a bit concerned. We are using 2.3, for what it’s worth, and even though it says “prerelease” it’s definitely the full retail payload. There’s a depressing reason for that... but in short, the “prerelease” builds put their DLLs inside our package, and the retail ones do not, and we _need_ that copy of their DLL. Which version of VS2019 are you seeing this with? The team has been building on 2019 since it came out, and hasn’t seen any trouble with the wildcards.

claunia commented

@DHowett-MSFT commented on GitHub (Apr 21, 2020):

Thanks for looking into this! I’m a bit concerned. We are using 2.3, for what it’s worth, and even though it says “prerelease” it’s definitely the full retail payload. There’s a depressing reason for that... but in short, the “prerelease” builds put their DLLs inside our package, and the retail ones do not, and we need that copy of their DLL.

Which version of VS2019 are you seeing this with? The team has been building on 2019 since it came out, and hasn’t seen any trouble with the wildcards.

@DHowett-MSFT commented on GitHub (Apr 21, 2020): Thanks for looking into this! I’m a bit concerned. We are using 2.3, for what it’s worth, and even though it says “prerelease” it’s definitely the full retail payload. There’s a depressing reason for that... but in short, the “prerelease” builds put their DLLs inside our package, and the retail ones do not, and we _need_ that copy of their DLL. Which version of VS2019 are you seeing this with? The team has been building on 2019 since it came out, and hasn’t seen any trouble with the wildcards.

claunia commented

@jtippet commented on GitHub (Jul 7, 2020):

@DHowett-MSFT - may I request updating MUX again to 2.5.0-prerelease.200609001? That version contains a couple important fixes to unblock a fix for this issue:

With that version of MUX, Terminal is very close to being beautiful in all HC themes. Here's a peek at what it looks like with the newer MUX and a change to set Terminal to ApplicationHighContrastAdjustment::None:

Compare that to the screenshot at the top of this thread, and I think it's clearly an improvement. The menu is rather less embarrassing too:

Current	2.5.0 + `AHCA::None`

As a bonus, by updating to 2.5.0, you'll also get rounded tab feet, which is catnip for tab nerds:

@jtippet commented on GitHub (Jul 7, 2020): @DHowett-MSFT - may I request updating MUX again to 2.5.0-prerelease.200609001? That version contains a couple important fixes to unblock a fix for this issue: * https://github.com/microsoft/microsoft-ui-xaml/pull/2446 * https://github.com/microsoft/microsoft-ui-xaml/pull/2377 With that version of MUX, Terminal is very close to being beautiful in all HC themes. Here's a peek at what it looks like with the newer MUX and a change to set Terminal to `ApplicationHighContrastAdjustment::None`: ![image](https://user-images.githubusercontent.com/10259764/86704670-fa7c4000-bfc9-11ea-9a4c-8ee167568ecf.png) Compare that to the screenshot at the top of this thread, and I think it's clearly an improvement. The menu is rather less embarrassing too: | Current | 2.5.0 + `AHCA::None` | | --- | --- | | ![image](https://user-images.githubusercontent.com/10259764/86705949-3cf24c80-bfcb-11ea-99f4-2ba38d6778d3.png) | ![image](https://user-images.githubusercontent.com/10259764/86705963-411e6a00-bfcb-11ea-85f6-0e3786fecc07.png) | As a bonus, by updating to 2.5.0, you'll also get rounded tab feet, which is catnip for tab nerds: ![image](https://user-images.githubusercontent.com/10259764/86704754-0e27a680-bfca-11ea-82c6-e73e4be6c5d9.png)

claunia commented

@mimi89999 commented on GitHub (Jul 7, 2020):

Is there any progress on this issue? The latest preview from the Store still looks really bad

@mimi89999 commented on GitHub (Jul 7, 2020): Is there any progress on this issue? The latest preview from the Store still looks really bad ![Screenshot_win10_2020-07-07_11:53:22](https://user-images.githubusercontent.com/8530546/86764928-c85df300-c048-11ea-8bba-86e2d77b4eae.png)

claunia commented

@mimi89999 commented on GitHub (Jul 7, 2020):

Also, I noticed that some icons in the taskbar change to monochrome and others don't. Why?

@mimi89999 commented on GitHub (Jul 7, 2020): Also, I noticed that some icons in the taskbar change to monochrome and others don't. Why?

claunia commented

@zadjii-msft commented on GitHub (Jul 7, 2020):

@jtippet absolutely lets update! Kinda funny that we only just got on 2.4 (#5778) a few days before the 2.5 prerelease came out 😃

@zadjii-msft commented on GitHub (Jul 7, 2020): @jtippet absolutely lets update! Kinda funny that we only just got on 2.4 (#5778) a few days before the 2.5 prerelease came out 😃

claunia commented

@jtippet commented on GitHub (Jul 7, 2020):

Is there any progress on this issue? The latest preview from the Store still looks really bad

There's definitely been progress -- comparing your original screenshot with your current one, you can see that the tab titles look better. That's fix 1663 in MUX, which already shipped in the store version of Terminal. The menu will be improved a bit once #6819 lands, and then there's really only one more line of code to add to Terminal to make everything look like the screenshot I shared.

Also, I noticed that some icons in the taskbar change to monochrome and others don't. Why?

The OS never automatically generates monochrome icons from a full-color icon. It would rarely look great, and in some cases, would make an unreadable mess.

For the app launcher icons in the center of the taskbar, the shell relies on the app to provide a hand-crafted high contrast icon. But only UWP has the technology to designate an icon as being for high contrast -- classic win32 resources don't even have the concept. (Classic win32 can only tailor icons for display scale and color bitdepth, the latter of which is entirely obsolete, since nobody's rocking an EGA display anymore.) So a UWP app can display colorful icons when HC is disabled, while automatically switching to monochrome icons when HC is enabled. But a Win32 app has to choose one or the other, and can't adapt to the HC setting. That's why, in your screenshot, the File Explorer icon is not monochrome: File Explorer is a win32 app.

Furthermore, an app will only change its icon if the app developer's art department actually troubled themselves to provide a high contrast version of the icon. That's why, in your screenshot, Terminal does not have a monochrome icon: the Terminal art department did not provide one. Although if you have more pixel talents than I, perhaps the Terminal team would accept a contribution of beautiful new HC icons? See here.

Hopefully, as Project Reunion makes UWP technology more readily available, more developers will include high contrast icons with their apps.

@jtippet commented on GitHub (Jul 7, 2020): > Is there any progress on this issue? The latest preview from the Store still looks really bad There's definitely been progress -- comparing your original screenshot with your current one, you can see that the tab titles look better. That's fix 1663 in MUX, which already shipped in the store version of Terminal. The menu will be improved a bit once #6819 lands, and then there's really only one more line of code to add to Terminal to make everything look like the screenshot I shared. > Also, I noticed that some icons in the taskbar change to monochrome and others don't. Why? The OS never automatically generates monochrome icons from a full-color icon. It would rarely look great, and in some cases, would make an unreadable mess. For the app launcher icons in the center of the taskbar, the shell relies on the app to provide a hand-crafted high contrast icon. But only UWP has [the technology](https://docs.microsoft.com/en-us/windows/uwp/app-resources/tailor-resources-lang-scale-contrast) to designate an icon as being for high contrast -- classic win32 resources don't even have the concept. (Classic win32 can *only* tailor icons for display scale and color bitdepth, the latter of which is entirely obsolete, since nobody's rocking an EGA display anymore.) So a UWP app can display colorful icons when HC is disabled, while automatically switching to monochrome icons when HC is enabled. But a Win32 app has to choose one or the other, and can't adapt to the HC setting. That's why, in your screenshot, the File Explorer icon is not monochrome: File Explorer is a win32 app. Furthermore, an app will only change its icon if the app developer's art department actually troubled themselves to provide a high contrast version of the icon. That's why, in your screenshot, Terminal does not have a monochrome icon: the Terminal art department did not provide one. Although if you have more pixel talents than I, perhaps the Terminal team would accept a contribution of beautiful new HC icons? See [here](https://github.com/microsoft/terminal/tree/master/res/terminal/images). Hopefully, as Project Reunion makes UWP technology [more readily available](https://docs.microsoft.com/en-us/windows/uwp/app-resources/using-mrt-for-converted-desktop-apps-and-games), more developers will include high contrast icons with their apps.

claunia commented

@mimi89999 commented on GitHub (Jul 7, 2020):

There's definitely been progress -- comparing your original screenshot with your current one, you can see that the tab titles look better. That's fix 1663 in MUX, which already shipped in the store version of Terminal. The menu will be improved a bit once #6819 lands, and then there's really only one more line of code to add to Terminal to make everything look like the screenshot I shared.

Ah. OK. I see that the tabs look good now, but the + and arrow down buttons still have a background. I thought that they also would be fixed since in the animation in https://github.com/microsoft/microsoft-ui-xaml/pull/1663#issuecomment-557915281 those buttons also don't have the background anymore.

For the app launcher icons in the center of the taskbar, the shell relies on the app to provide a hand-crafted high contrast icon. But only UWP has the technology to designate an icon as being for high contrast...

Thanks for this long explanation. Hopefully Terminal will get a monochrome icon soon 😉
As for old Win32 apps, I saw that MS made a nonofficial API for dark theme especially for Explorer. AFAIK only Explorer and Recorder are using it. Somebody managed to enable it: https://github.com/ysc3839/win32-darkmode. Maybe they will do the same for icons? I don't see them anywhere close to rewriting old Win32 apps. Anyway, that's off topic here...

@mimi89999 commented on GitHub (Jul 7, 2020): > There's definitely been progress -- comparing your original screenshot with your current one, you can see that the tab titles look better. That's fix 1663 in MUX, which already shipped in the store version of Terminal. The menu will be improved a bit once #6819 lands, and then there's really only one more line of code to add to Terminal to make everything look like the screenshot I shared. Ah. OK. I see that the tabs look good now, but the `+` and arrow down buttons still have a background. I thought that they also would be fixed since in the animation in https://github.com/microsoft/microsoft-ui-xaml/pull/1663#issuecomment-557915281 those buttons also don't have the background anymore. > For the app launcher icons in the center of the taskbar, the shell relies on the app to provide a hand-crafted high contrast icon. But only UWP has the technology to designate an icon as being for high contrast... Thanks for this long explanation. Hopefully Terminal will get a monochrome icon soon :wink: As for old Win32 apps, I saw that MS made a nonofficial API for dark theme especially for Explorer. AFAIK only Explorer and Recorder are using it. Somebody managed to enable it: https://github.com/ysc3839/win32-darkmode. Maybe they will do the same for icons? I don't see them anywhere close to rewriting old Win32 apps. Anyway, that's off topic here...

claunia commented

@jtippet commented on GitHub (Jul 7, 2020):

I thought that they also would be fixed since in the animation in microsoft/microsoft-ui-xaml#1663 (comment) those buttons also don't have the background anymore.

Yeah, I fixed the standard TabView [+] icon that ships with MUX. But Terminal doesn't use the standard icon. It builds its own from scratch, so it can have the dropdown menu. Don't worry though: I'm fixing Terminal's [+] button too: #6812

As for old Win32 apps, I saw that MS made a nonofficial API for dark theme especially for Explorer.

You can definitely write code to detect whether HC is enabled, and if so, query the background color. You don't even need undocumented APIs -- just query SPI_GETHIGHCONTRAST. So you can already write a win32 app that draws a beautiful icon in all modes. But the taskbar problem that you're seeing is different: the app isn't drawing the icons, so there's no amount of code you can add to the app to fix the problem. There are various OS surfaces (taskbar, start menu, alt+tab, task manager, ...) where the OS draws an icon on behalf of your app. In those cases, the OS needs to know which of your icons to use. UWP has a sophisticated metadata system, so for example you can describe an icon as being designed for 200% DPI + high contrast black theme + fr_CA locale. The OS will inventory all your icons, sift through the metadata, then select the best icon for the current situation. Compare that to Win32, where the icon can only talk about pixels and color depth -- there's simply no way for you to say that a particular icon is designed to look great in HC black theme.

@jtippet commented on GitHub (Jul 7, 2020): > I thought that they also would be fixed since in the animation in microsoft/microsoft-ui-xaml#1663 (comment) those buttons also don't have the background anymore. Yeah, I fixed the standard TabView [+] icon that ships with MUX. But Terminal doesn't use the standard icon. It builds its own from scratch, so it can have the dropdown menu. Don't worry though: I'm fixing Terminal's [+] button too: #6812 > As for old Win32 apps, I saw that MS made a nonofficial API for dark theme especially for Explorer. You can definitely write code to detect whether HC is enabled, and if so, query the background color. You don't even need undocumented APIs -- just query `SPI_GETHIGHCONTRAST`. So you can already write a win32 app that draws a beautiful icon in all modes. But the taskbar problem that you're seeing is different: the app isn't drawing the icons, so there's no amount of code you can add to the app to fix the problem. There are various OS surfaces (taskbar, start menu, alt+tab, task manager, ...) where the OS draws an icon _on behalf of_ your app. In those cases, the OS needs to know which of your icons to use. UWP has a sophisticated metadata system, so for example you can describe an icon as being designed for 200% DPI + high contrast black theme + fr_CA locale. The OS will inventory all your icons, sift through the metadata, then select the best icon for the current situation. Compare that to Win32, where the icon can only talk about pixels and color depth -- there's simply no way for you to say that a particular icon is designed to look great in HC black theme.

claunia commented

@ghost commented on GitHub (Jul 21, 2020):

:tada:This issue was addressed in #6915, which has now been successfully released as Windows Terminal v1.1.2021.0.🎉

Handy links:

@ghost commented on GitHub (Jul 21, 2020): :tada:This issue was addressed in #6915, which has now been successfully released as `Windows Terminal v1.1.2021.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.1.2021.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)

claunia commented

@ghost commented on GitHub (Jul 22, 2020):

:tada:This issue was addressed in #6915, which has now been successfully released as Windows Terminal v1.1.2021.0.🎉

Handy links:

@ghost commented on GitHub (Jul 22, 2020): :tada:This issue was addressed in #6915, which has now been successfully released as `Windows Terminal v1.1.2021.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.1.2021.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)

claunia commented