You are here

[Fixed] Some text in platform updater/app store, backup/restore, PA.c installer, etc invisible w high contrast Windows theme

11 posts / 0 new
Last post
Martin0815
Martin0815's picture
Offline
Last seen: 6 years 1 month ago
Joined: 2009-12-19 15:28
[Fixed] Some text in platform updater/app store, backup/restore, PA.c installer, etc invisible w high contrast Windows theme

Hi,

Since I having eye disabilities I use the enabled black based High-Contrast-Mode (high-contrast-#1 theme/design) on Windows 7 and Windows 10.

Since the installer and the updater are strictly "branded" with white background images, there is already a problem, since white as background is not that "mandatory" (MSDN rules) high-contrast support.

On Windows 7 the text in the installer or at the last updater screen is yellow and so yellow on white background image.
On Windows 10 it is white texto n white background image.

To test it on your self:

  • use LeftShift+LeftAlt+PrintScr to enable or diable the high-contrast-mode
  • switch through the high-contrast designs to test the visual results.

I really would appreciate, if some changes will take place to support accessibility helpers (MSDN: mandatory accessibility support).

Best regards,

Martin
P.S.: Desktop Zoom is mostly ignored, too on my Windows 7 office desktop.

John T. Haller
John T. Haller's picture
Online
Last seen: 43 min 27 sec ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
NSIS

The platform's installer and updater/app store as well as the portableapps.com installers are written in NSIS. This is a widely-used open source installer (Firefox, 7-Zip, and lots of other projects use it). You'd need to ask them about full compatibility with high contrast themes.

Side Note: The main bits of the installer, updater, and app store do work with the high contrast theme already, at least on Windows 10. I think I may be able to at least manually detect the high contrast theme and force the white text to black in the affected areas with a bit of work. For note, the affected areas are the welcome/finish pages as well as the headers throughout.

Sometimes, the impossible can become possible, if you're awesome!

Martin0815
Martin0815's picture
Offline
Last seen: 6 years 1 month ago
Joined: 2009-12-19 15:28
You design the installer appearance and I should …

Sorry, but do I understand it correctly?

Someone decides to include a white big bitmap and to use white backgrounds for "branding" and I should ask the Installer people to change this?

Hhm - you are not that wrong, but if they would disable your branding, because of high-contrast-mode - automatically - would you be glad of it? I would!
But at first I would ask the configurator of the installer to think about the design to be mandatory, or if this design could be changed!

I had similar "Tickets" with other software developers and companies and most of them simply changed their installer configuration to have smaller bitmaps with original branding and much bigger system color using window background. This way system color using text was always visible and readable.

But eventually you are right. NSIS & Co should automatically switch off branding, design to support handicapped people in the most efficient way.

About the "main bits".

If installer work mostly with high-contrast, than it is quiet good.
But if (initial and/or final) messages are unreadable - due to branding/corporate design - than accepting mostly high-contrast-mode is not enough.

Martin Lemburg, Berlin / Germany

John T. Haller
John T. Haller's picture
Online
Last seen: 43 min 27 sec ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Not an Image, Not Something We Set, Not a Design Choice

It's not an image. The actual window background itself is set to forced white and doesn't pick up what Windows says theme-wise. The welcome and finish page have an image on the left (for text modes that read left to right) and then no image the rest of the window, that's all just window controls and form background. The header image isn't full width either, it's just the right-most 150px (again for text modes that read left to right). The left part of the header is just form background and window controls.

So, it's not something we designed or set. It doesn't matter what images we use, even if they were just 100% black. The actual NSIS installer works the same way. As does a basic MUI one.

So, I'm trying to figure out a way to detect whether a high contrast theme is enabled or not. And then if so, which one is enabled. Unfortunately, it's more complicated than can be accomplished within NSIS scripting easily as you have to create a HIGHCONTRAST structure (which NSIS isn't designed for), run some code on it, and feed it to a specific Windows API which will tell you whether high contrast is enabled or not once you then compare the compound result to a specific flag. But, that won't tell you which theme is enabled. Because it could be white (or another color) text on black... or it could be black text on a white background. So, that won't help us in terms of trying to manually work around the NSIS hard coding of color.

What I may do for now is force the text on welcome, finish, and the header to be black since the background is stuck as white. It won't match your selected theme, but it will at least be visible.

Sometimes, the impossible can become possible, if you're awesome!

Martin0815
Martin0815's picture
Offline
Last seen: 6 years 1 month ago
Joined: 2009-12-19 15:28
Not bad at all ...

Thanks for your explaining response.

No matter if I'm wrong with my assumptions or not. Some support teams changed their installers to be more "compatible" by using the system background color or like you suggested a defined black font color to prevent the usage of system colors for window text on white background.

I'm looking forward to have more readable information - even if it is only "Finished updating".

Thanks in n advance!

Best regards,

Martin

Martin Lemburg, Berlin / Germany

John T. Haller
John T. Haller's picture
Online
Last seen: 43 min 27 sec ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Other Installers, Pulling From Windows

Other installers like MSIs aren't affected. I'm not sure about InnoSetup offhand. NSIS itself seems to be hard coding those two areas (header and welcome/finish bg) to white for some reason, even though it picks up the Windows color settings for everything else. NSIS itself seems to respond in real time to both turning on and off high contrast. It's just those two areas that are hard coded to white, even though the text on those areas is responding to the change. Very odd.

I'm working on hard coding them to black text with scripting as each of the 'pages' of the installer loads. It won't match the selected Windows theme if you use a black background (though it would be fine if you select black text on white, of course) but it will at least be visible. It would become invisible if you switched high contrast on while the installer already had a page loaded, but as soon as you went forward or back a page it would be visible again.

Sometimes, the impossible can become possible, if you're awesome!

John T. Haller
John T. Haller's picture
Online
Last seen: 43 min 27 sec ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Labeled 'Bug', Development progress

I've changed the subject and labeled this a bug for tracking purposes.

For any developers following along, here is the code to run on a page's show function to force the header to be black text sop it's visible on the forced white background (including a PUSH/POP to ensure we don't dirty any variables):

PUSH $0
FindWindow $0 "#32770" "" $HWNDPARENT
GetDlgItem $0 $HWNDPARENT 1037
SetCtlColors $0 0x000000 0xFFFFFF
GetDlgItem $0 $HWNDPARENT 1038
SetCtlColors $0 0x000000 0xFFFFFF
POP $0

I can't get something similar working on welcome/finish yet even when using the appropriate window handle.

UPDATE2: With the welcome pages in conjunction with MUI2, the following code in a custom show handlers will force black text on a white background:

SetCtlColors $mui.WelcomePage.Title 0x000000 0xFFFFFF
SetCtlColors $mui.WelcomePage.Text 0x000000 0xFFFFFF

And with finish, it's a bit more complicated:

SetCtlColors $mui.FinishPage.Title 0x000000 0xFFFFFF
SetCtlColors $mui.FinishPage.Text 0x000000 0xFFFFFF
${If} $bolHighContrast == "true"
  ;Annoying hack to ensure checkboxes are visible when high contrast is on
  SetCtlColors $mui.Finishpage.Run 0x000000 0x888888
  SetCtlColors $mui.FinishPage.ShowReadme 0x000000 0x888888
${EndIf}

Unfortunately, you can't properly set checkbox fore color. Only the background. So, this is an annoying hack to set the checkbox background to 50% gray. This ensures it's somewhat visible for both the standard white or yellow text as well as the less common black text high contrast themes.

I still can't yet determine high contrast use within NSIS itself but can determine it in the platform. So the platform can pass it along to apps as well as to backup/restore and app store/updater when necessary. The next platform release will set an environment variable called PortableApps.comHighContrast. To pull it into an NSIS variable, define it and then put this in .onInit:

ReadEnvStr $bolHighContrast "PortableApps.comHighContrast"

I'll continue updating as I make more progress.

UPDATE3: I've refined the header hack into an easily-inserted macro that works for both MUI version 1 and 2. Including this macro will let you just call ${PageHeaderHackForHighContrast} in your show function:

!define PageHeaderHackForHighContrast "!insertmacro PageHeaderHackForHighContrast"
!macro PageHeaderHackForHighContrast
	!if ${MUI_SYSVERSION} >= 2
		SetCtlColors $mui.Header.Text 0x000000 0xFFFFFF
		SetCtlColors $mui.Header.SubText 0x000000 0xFFFFFF
	!else
		Push $0
		FindWindow $0 "#32770" "" $HWNDPARENT
		GetDlgItem $0 $HWNDPARENT 1037
		SetCtlColors $0 0x000000 0xFFFFFF
		GetDlgItem $0 $HWNDPARENT 1038
		SetCtlColors $0 0x000000 0xFFFFFF
		Pop $0
	!endif
!macroend

Sometimes, the impossible can become possible, if you're awesome!

John T. Haller
John T. Haller's picture
Online
Last seen: 43 min 27 sec ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Fixed and worked around in PortableApps.com Installer 3.5.2,...

This is fixed and worked around in today's release of the PortableApps.com Installer 3.5.2. The welcome and finish screens as well as the header are forced to black text regardless of Windows' settings to be visible on the background which is locked to white by NSIS itself. There is an issue with the one or two check boxes on the final screen (run, read log, etc) where they will not accept a changed color and will use Windows' colors. In this instance, it will look for an environment variable called PortableApps.comHighContrast and if it is set to true, it will force a gray background behind both checkboxes and text. The next release of the PA.c Platform will set this environment variable automatically based on your Windows theme setting. You can force this mode on by setting that environment variable to true at the Windows level or you can test it by creating a batch file called test.bat or similar next to the PortableApps.comInstaller_3.5.2.paf.exe installer with these lines in it:

Set PortableApps.comHighContrast=true
PortableApps.comInstaller_3.5.2.paf.exe

The above-mentioned changes affect both the PortableApps.com Installer's generation wizard as well as all the app installers it generates. Today's updated apps all use this new installer so should be visible in high contrast now.

I will continue updating the platform for the next release with similar changes to the PA.c App Store/Updater, Backup/Restore utility, and the platform's installer as well. This bug will remain open until then.

Sometimes, the impossible can become possible, if you're awesome!

John T. Haller
John T. Haller's picture
Online
Last seen: 43 min 27 sec ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
PortableApps.comHighContrast environment variable in 14.4.2+, 15

The environment variable PortableApps.comHighContrast is now set in the PortableApps.com Platform stable 14.4.2 and later as well as the 15.0 Beta 1 and later releases. This will allow installers and tools that are aware of it (like the PortableApps.com Installer generator and the PA.c Installers themselves) to automatically utilize it to fix checkboxes.

Sometimes, the impossible can become possible, if you're awesome!

John T. Haller
John T. Haller's picture
Online
Last seen: 43 min 27 sec ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Fixed in PA.c Platform 15 Beta 2

This should all be fixed in the new 15 Beta 2 release of the platform I just posted. I made the fixes to the updater/app store, backup, and restore. The bug will remain open pending stable release.

Sometimes, the impossible can become possible, if you're awesome!

John T. Haller
John T. Haller's picture
Online
Last seen: 43 min 27 sec ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Fixed in 15.0

The above-mentioned fixes have all landed in the stable channel with the 15.0 release.

Sometimes, the impossible can become possible, if you're awesome!

Log in or register to post comments