Add support for accent color saturation level

[WinExperiments]

This new version allows you to use any accent color, such as gray, brown, etc. Designed to colorize the default Windows 11 visual style and Rectify11's custom visual styles. Does not have the Windows version checks apart from the taskband ExtendedUI buttons.

[WinExperiments]

This does not mean it does not work on Windows Vista to 10, in fact, it should work as intended. My main concern was Windows 11.

[OrthodoxWindows]

I just realized that we forked the project almost at the same time lol.

[WinExperiments]

@OrthodoxWindows Try out my new version, you'll like it.

[OrthodoxWindows]

@OrthodoxWindows Try out my new version, you'll like it.

Indeed, your changes fix all the problems I was having. Thank you very much.

However, I still see one element not colorized ; these are some frames related to the Basic theme (if you use the Basic theme with DWM, you have to use this Windhawk mod to enable them) in the Aerolite style :

For some reason, in the Aero style, it seems to be colorized correctly :

[WinExperiments]

@krlvm This one has full HSL support, meaning the bitmaps change according to the different brightness levels of accent colors. It fully works on the Rectify11 visual styles (light and dark), but on the Microsoft ones (Windows 10/11), the Explorer list views do not support all colors and may turn into weird colors. I thought it was the transparent pixels but they colorize perfectly with the Rectify11 styles. I tried multiplying the saturation by 0.9 and that workaround works but the colors are more inaccurate.

[krlvm]

This is still very cool, I'll think about how I can help this evening and we'll merge it into the upstream

[WinExperiments]

Have you checked the code?

[krlvm]

Currently it breaks with light orange color:

[krlvm]

(just for record, will check what we can do with it)

[WinExperiments]

Interestingly enough, the correct colors show up if you have the items grouped and click the expand/collapse button. They only show up when the animation is playing, when it finishes, the broken color comes back.

[krlvm]

Interestingly enough, the correct colors show up if you have the items grouped and click the expand/collapse button. They only show up when the animation is playing, when it finishes, the broken color comes back.

The (almost) correct color is also applied to the ListView items focused state

[WinExperiments]

Does this fix the color issue?

[krlvm]

Yes, it works much better. Thank you!

However, if you set accent color back to Standard Blue, everything looks undersaturated in comparasion to the default colors - where did you get g_hslDefaultAccent values from?

[WinExperiments]

This is almost perfect, its only bug is when the theme is changed, it applies a weird light gray color and changing the accent color to a normal one gives wrong lightness values and gradients are completely ruined.

[WinExperiments]

Oh and I also forgot to restore the menu/progress bar checks since this is aimed at Rectify11.

[WinExperiments]

@krlvm I think we should make the program restart itself when WM_THEMECHANGED is sent but I don't know how to do that.

[OrthodoxWindows]

Oh and I also forgot to restore the menu/progress bar checks since this is aimed at Rectify11.

Do you plan to fix the issue with some Basic window frames in the Aerolite style ? (as I described above)

[WinExperiments]

@OrthodoxWindows Aerolite uses a fillcolor for that frame which AccentColorizer cannot colorize. It can only colorize bitmaps.

[WinExperiments]

@krlvm Have you figured out why theme changing is broken?

[krlvm]

I will check soon, thank you

[WinExperiments]

Update: I got hue and saturation, but lightness is still not accurate. Gradients are smooth which means the lightness proportions are correct.

[WinExperiments]

Update 2: It's now fixed! (though it seems to work when I build it as debug only)

[WinExperiments]

~It also works when I build it as Release Static... why is Release broken?~ Doesn't work after a few theme changes as well.

[WinExperiments]

@krlvm Any update? If you can make it work on Release just like how it does on Debug, then we can ship it

[krlvm]

I'll check it now, thanks

[krlvm]

Did you mean launching Release builds or running it? There was a mistake in the build configuration, which prevented Release builds from being launched from VS.

As for the results, I don't see any difference from Debug.

It's as if there is no idempotency now - after each restart of the program the colors become darker and darker.

[WinExperiments]

It's as if there is no idempotency now - after each restart of the program the colors become darker and darker. What do you do to get the colors darker?

[krlvm]

I just kill and start the process again, so it recolorizes everything one more time

[krlvm]

You can also change accent colors back and forth a few times and then check the produced color with a graphics editor - it will change

[WinExperiments]

I just kill and start the process again, so it recolorizes everything one more time

Yes, I have not addressed this issue. I always assumed users would start it once until they restart the device (which resets bitmaps back to default colors). I guess we can save the g_oldhslAccentS and g_oldhslAccentL values get saved in a way that is preserved even if AccentColorizer is not running?

[WinExperiments]

You can also change accent colors back and forth a few times and then check the produced color with a graphics editor - it will change

Is it a big difference in the colors? I mean back then it was very easy to notice but I've improved the accuracy over time -- I know it is not 100% perfect but it's still very close. I guess it's fractional imperfections in the RGB to HSL logic

[krlvm]

We can store currently applied accent color in registry

[WinExperiments]

Why do we need to store the accent color? We only need to store g_oldhslAccentS, g_oldhslAccentL, and g_oldhslEnhancedAccentL right?

[krlvm]

Yes, that's what I meant, but we can also store the color itself to avoid re-application

[WinExperiments]

As for the results, I don't see any difference from Debug.

Have you tried to change the theme (visual style)? Changing from Windows default to High Contrast and back to Windows default is enough -- no custom visual style needed. You'd also need a desaturated accent color (like the "Iris pastel" or "Camouflage desert" colors in the Windows presets) to notice it. The saturation is ignored and lightness is inaccurate when I use Release but that doesn't happen on Debug

[WinExperiments]

@krlvm Now that I tried launching the release build from VS itself, it works normallyit is still flawed. Have you tried building it? I'll try building it with your new configuration and retest it. Same results on the built version.

[WinExperiments]

It looks like it doesn't apply the saturation and lightness changes when the theme is changed, but does when you change the accent color after that (on Release). On Debug, everything is done correctly. Why does Release ignore them at theme change?

[krlvm]

It looks like it doesn't apply the saturation and lightness changes when the theme is changed, but does when you change the accent color after that (on Release). On Debug, everything is done correctly.

What's the sequence? Switch to a high contrast theme, go back and change the accent color?

[WinExperiments]

What's the sequence? Switch to a high contrast theme, go back and change the accent color?

Yes, also, the accent color prior to theme change should be desaturated (like "Iris pastel" or "Camouflage desert" from the Windows presets)

[krlvm]

I can't reproduce it on Windows 10 neither on Release nor on Debug builds, do you use Windows 11?

[WinExperiments]

Yes I use Windows 11, I also tried on 3 different visual styles. Did you use one of the colors I asked you to use?

[krlvm]

Yes, I did with both colors. Maybe it's a Windows 11 specific problem, I'll get a VM and check.

[WinExperiments]

Maybe it's a Windows 11 specific problem, I'll get a VM and check.

I don't know. If you wonder what build I'm running, it's 22621.382

[WinExperiments]

@krlvm Have you tested it on Windows 11?

[OrthodoxWindows]

@OrthodoxWindows Aerolite uses a fillcolor for that frame which AccentColorizer cannot colorize. It can only colorize bitmaps.

However, many Aerolite style elements do not use bitmaps, yet they are correctly colorized. Its strange.

[WinExperiments]

However, many Aerolite style elements do not use bitmaps, yet they are correctly colorized. Its strange.

They use ColorList. ColorList is not the same as FillColor.

[OrthodoxWindows]

However, many Aerolite style elements do not use bitmaps, yet they are correctly colorized. Its strange.

They use ColorList. ColorList is not the same as FillColor.

Thank you, I understand better. While exploring the visual style, I noticed that elements that use FillColor are rare. Overall, I think I'll modify aerolite to fix the issue (just like I'll modify aero to fix the basic frame Windows 7 styling issue).

[krlvm]

@krlvm Have you tested it on Windows 11?

I haven't had time yet, but I'll try soon

[WinExperiments]

@krlvm Have you done any further tests? It's been 2 months

[WinExperiments]

Update: Behavior is different on a more updated 22621 build.

Changing themes now gives a half-saturated default accent color.