Closed wiktorwiktor12 closed 2 weeks ago
This looks like a compatibility issue with AWM or other windhawk mods, as I noticed that the Restore Windows 7 Title Bar Buttons mod written by @Dulappy retains a reference to CTopLevelWindow::UpdateColorizationColor, even though it doesn't affect OpenGlass. It would be nice if this could be fixed by something other than OpenGlass, after all GetWindowColorizationColor automatically calculates the exact title bar color based on the system settings.
This looks like a compatibility issue with AWM or other windhawk mods, as I noticed that the Restore Windows 7 Title Bar Buttons mod written by @Dulappy retains a reference to CTopLevelWindow::UpdateColorizationColor, even though it doesn't affect OpenGlass. It would be nice if this could be fixed by something other than OpenGlass, after all GetWindowColorizationColor automatically calculates the exact title bar color based on the system settings.
It isn't, as this can be fixed openglass side.
Obviously it's not possible to reproduce this problem on a clean install of Windows, which suggests that it's not a bug. This is actually quite similar to the problem caused by the CTopLevelWindow::TreatAsActiveWindow hook. Perhaps there is a CGlassColorizationParameters::AdjustWindowColorization hook now I guess.
This looks like a compatibility issue with AWM or other windhawk mods, as I noticed that the Restore Windows 7 Title Bar Buttons mod written by @Dulappy retains a reference to CTopLevelWindow::UpdateColorizationColor, even though it doesn't affect OpenGlass. It would be nice if this could be fixed by something other than OpenGlass, after all GetWindowColorizationColor automatically calculates the exact title bar color based on the system settings.
I mean if it is an issue with AWM then you can check it out yourself as its open source now https://github.com/Dulappy/aero-window-manager/tree/main
I've just compiled AWM myself and it seems that OpenGlass runs fine with AWM except for the custom msstyle feature that doesn't work, but the color settings are perfectly fine. So I guess it could be a problem with other windhawk mods as well, which can be verified with a memory dump of dwm. I guess I could consider replacing GetWindowColorizationColor with a direct read of the colors stored in CTopLevelWindow, which would avoid being interfered with by other windhawk mods and also allow me to use AWM's color settings.
CTopLevelWindow stores colors in scRGB format, which can't be used directly, so I added the option to read accent colors in the new version.
For me and many others, GetWindowColorizationColor does not return the correct colour for the windows, instead it returns the colour black, in my local fork of OpenGlass, I propose adding a setting to take the window colour from the AccentColor reg key instead of using GetWindowColorizationColor, this would need to be cached of course as reading registry every time you need to get the colour to render is not efficient.