DwmColorBlurMica

[WildByDesign]

It turns out that WinGetTitle was also the source of the brief white flicker on the title bar.

After switching to a class name based filtering, the flicker is gone and everything is even faster.

[WildByDesign]

I just updated the first post with version 0.6.

TL;DR - Check first post for changelog and source.

I did not end up going with only class name for the initial event hook. I was up to 20-25 lines just to avoid class names for windows which had no title. That was fast but too problematic and the list would only grow.

Nothing beat the "filter all blank titles" rule If $sActiveWindow = "" Then ContinueCase from @argumentum original script derived from WinGetTitle. The only problem is that WinGetTitle was identified as causing lag, much higher CPU usage and under rare situations it would freeze the entire script.

I had tried _WinAPI_GetWindowText before but it always gave inconsistent results. So I modified it and fixed the problem:

Func _WinAPI_GetWindowTextMod($hWnd)
    Local $sActiveWindow
    Local $aCall = DllCall("user32.dll", "int", "GetWindowTextW", "hwnd", $hWnd, "wstr", "", "int", 4096)
    If @error Or Not $aCall[0] Then
        $sActiveWindow = ""
        Return $sActiveWindow
    EndIf

    Return $aCall[2]
EndFunc

This fixed the lag issue, lowered CPU usage to almost nothing, made the whole event hook faster (little to no flicker) and fixed the rare issue of the entire script freezing under certain circumstances. That freeze was something that I could reproduce consistently before but it's gone now. I know I used the term "night and day" difference on a recent release, but that was nothing compared to this.

I don't know why WinGetTitle is so slow because I can't see the code for it. But stay away from it in any situations where it gets called many times and performance matters.

I also added wildcards for the inclusion/exclusion lists. The wildcards can be added at the beginning and/or end, not in the middle. For example, you could do *WndClass* which would then cover like 5 or 6 different classes at once. You could do C:\Windows\notepad.exe or even simply *notepad*. You get the idea.

[WildByDesign]

The first post has been updated to version 0.7.

The overall speed of the event hook is faster in this release which is nice. I cleaned up the event hook function to make it perform better.

This release is mostly geared toward improving the File Explorer handling in the hook. I had to differentiate between classic File Explorer and modern File Explorer. Classic File Explorer has no issues with DwmExtendFrameIntoClientArea or Blur Behind and therefore can be applied immediately and stays applied.

Modern File Explorer, on the other hand, is a "laggy" beast. It loses client area coloring from DwmExtendFrameIntoClientArea any time it loses and regains focus which I solved in a previous release. But it also doesn't always apply 100% of the time when you first start it due to a timing issue with how laggy it is. This can be different depending on the speed of any users' CPU. So I added ExplorerPaintDelay to the config file with a default value of 200ms which fixes it 100% of the time on my system. But I made it a config option because it might be different on other users' systems depending on hardware specs and how "laggy" modern File Explorer is.

Modern File Explorer sometimes had an issue applying Blur Behind when starting File Explorer. I noticed that if you click on the taskbar and back on File Explorer, it fixes it. I will try to fix it properly when I have more time, but for now I have fixed it (100%) with a workaround in the blur behind function:

If $sClassName = "CabinetWClass" Then
    WinActivate("[CLASS:Shell_TrayWnd]")
    WinActivate($hWnd)
EndIf

So that extra bit is only needed for File Explorer.

All handling of both classic and modern File Explorer is super smooth in this release. File Explorer startup, losing and regaining focus, etc. It all works beautifully. And all of that extra work was only needed because modern File Explorer is such a "laggy" monstrosity. Classic File Explorer is and was always fast. Modern File Explorer has always been slow and "laggy" and Microsoft seems to have no desire to improve it.

[WildByDesign]

Version 0.8 has been added to the first post.

There were two goals for this release. The first was to complete the Blur Behind feature and the second was more performance improvements to the event hook.

The Blur Behind had an issue where the titlebar would lose the blur after losing and regaining focus. I fixed that and it's working 100% now with the exception of modern File Explorer. Modern File Explorer required some special handling in the event hook. Blur Behind is complete now and fabulous.

The event hook is basically instantaneous now. I created a testing script that runs through the functions used in my event hook 100,000 times to get a timediff. The results helped me tidy up, modify and organize the functions in my event hook to improve performance a bit. I was able to improve the initial startup performance as well.

I am really thrilled with how much DwmColorBlurMica has evolved and improved. I have learned a lot from this.

[WildByDesign]

In 0.9 (just updated first post), I added the ability to change the titlebar text color.

Changing the titlebar text color is generally not needed. If you change the titlebar background color, the OS will generally (automatically) change the titlebar text color to something that is legible. However, if the option is available to change the titlebar text color in case someone wants to have fun with it. There may also be certain circumstances with Blur Behind that could benefit from changing the text color.

I finally updated the documentation file (DwmColorBlurMica.txt) with some OS requirements for the different API calls and some general info.

[WildByDesign]

I just updated the first post with version 0.9.1.

I improved the custom hook handling for modern File Explorer to what seems like perfection on my system. But most importantly, I added custom hook handling for Windows Terminal. So if you love Windows Terminal and want to style it, you can now.

Good news: You do NOT have to install any custom msstyles (like Rectify11 Black Mica theme) to enjoy this feature for Terminal. That is because Terminal already uses DwmExtendFrameIntoClientArea and therefore I only needed to change the backdrop type or enable blur behind. It involved a lot more than just that, but that is why you don't need a custom msstyles. You can use this just fine with default Windows Aero dark theme.

Screenshots:

Spoiler

 

Note: While you don't need to install any custom msstyles, you do need to modify the theme details inside of the Windows Terminal settings.

Location: C:\Users\~your-user-name~\AppData\Local\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json

You need to add the following theme details at the appropriate place in the file:

Spoiler

"theme": "myNewTheme",
    "themes": 
    [
        {
            "name": "myNewTheme",
            "tab": 
            {
                "background": null,
                "iconStyle": "default",
                "showCloseButton": "always",
                "unfocusedBackground": "#00000000"
            },
            "tabRow": 
            {
                "background": "#00000000",
                "unfocusedBackground": "#00000000"
            },
            "window": 
            {
                "applicationTheme": "dark",
                "experimental.rainbowFrame": false,
                "frame": null,
                "unfocusedFrame": null,
                "useMica": true
            }
        }
    ],

 

 

Edited June 6 by WildByDesign

[WildByDesign]

Also regarding Windows Terminal custom handling, it is disabled by default in the config file. You would need to change WindowsTerminalHandling to True.

If you want Blur Behind, under [ClassInclusion], you can add CASCADIA_HOSTING_WINDOW_CLASS to include it OR under [ProcessInclusion], you can add WindowsTerminal.exe (you don't need to include it in both sections, just one or the other)

Edited June 6 by WildByDesign

[WildByDesign]

With 0.9.2, I finally figured out how to accurately and efficiently color the borders of only the active window. So once that window loses focus, it will lose the border color. Since this is the behaviour that Microsoft also uses, I have made this the new default.

I have added BorderColorOptions=0 to the [Configuration] section of the config file which will color only the active window.

@argumentum I know that you (and maybe other users) prefer to color the border colors of all windows (active and inactive) and therefore I have made it so that you can use  BorderColorOptions=1 to bring back the default behaviour.

[WildByDesign]

I just updated the first post with version 0.9.3. In this release, I got an accidental performance boost out of the event hook.

I fixed an issue where sometimes Windows Terminal would receive the colored borders and sometimes not. I also improved the timing of the File Explorer event hook and it is so consistent now that I don't think the ExplorerPaintDelay is needed anymore for modern File Explorer. I will likely remove it in the next release.

So Windows Terminal and File Explorer are so smooth and consistent now and working 100% of the time on my system. I believe that the timing is close to perfect now.

I accidentally got a nice performance boost after rearranging a few things in the event hook and removing a couple of events that were no longer needed since the above timing fixes  made them redundant. I was aiming for timing perfection. I wasn't really expecting a nice performance improvement in this release but I will take it.

[WildByDesign]

Minor (but nice) changes and fixes in 0.9.4. Check first post for Changelog.

[WildByDesign]

I'm working on a release that has full support for Visual Studio Code (plus VSCodium in my case) and Visual Studio 2022. Both are working beautifully and reliably. So I should be able to do a release soon after some more testing.

Screenshots:

Spoiler

 

[WildByDesign]

The first post has been updated with version 0.9.5.

The changelog isn't very big but it was a lot of work and a lot of testing to get Visual Studio 2022, Visual Studio Code and VSCodium to work with DwmExtendFrameIntoClientArea and Blur Behind. Visual Studio 2022 was actually quite easy. But dealing with Electron for VSCode was not fun. I updated the documentation file (DwmColorBlurMica.txt) with some details on how to get it working well with those apps and also Windows Terminal.

As a reminder, Visual Studio 2022, Visual Studio Code, VSCodium and Windows Terminal can enjoy DwmExtendFrameIntoClientArea and Blur Behind with the default Windows Dark (aero) theme. They do have their own special instructions, but they do not require installing a third-party msstyles at least.

[WildByDesign]

For anybody that is following this, I would like to add the ability to have per-app and per-class rules. Right now it is generally all global with per-app and per-class for ExtendToClient and BlurBehind.

I might need some help or recommendations for this. I don't know if my INI config file is adequate for this because it would be a bunch of duplicate key/value pairs and I don't think it would be proper with INI.

What I would like is to have all of the per-app and per-class rules loaded into an array. With that, I can very easily make the functions necessary. The part where I am stuck is choosing a config format (ini, json, xml, etc.) to load and save those rules. Choosing a format that will work and getting that stuff into an array in the first place is where I have been stuck for a few days now.

[ahmet]

What about sqlite database? You can have table names with prefixes or sufixes, ie. Calcultor_perApp, Class1_perClass, OtherClass_perClass. You can embed needed dll into script and load it from memory without writing to disk anything if the licence permits it.

Edited June 15 by ahmet

[water]

I use InireadSection and IniwriteSection to handle Ini-Files. Each section holds all keys/values belonging to the same "class". 
It only takes a single command to read all keys/values to a 2D array.
Works perfectly here  

[WildByDesign]

43 minutes ago, ahmet said:

What about sqlite database? You can have table names with prefixes or sufixes, ie. Calcultor_perApp, Class1_perClass, OtherClass_perClass. You can embed needed dll into script and load it from memory without writing to disk anything if the licence permits it.

Thank you. This is a possibility. I'm just looking through some of the _SQLite_* functions right now.

26 minutes ago, water said:

I use InireadSection and IniwriteSection to handle Ini-Files. Each section holds all keys/values belonging to the same "class". 
It only takes a single command to read all keys/values to a 2D array.

Thanks. That's interesting because I was playing around with IniReadSection yesterday and this morning a bit. I'm just trying to figure out if I should have one section for all custom rules and parse them accordingly into an array or multiple sections (a section for each custom rule) and parse into array.

Multiple would be something like:

Spoiler

[CustomRules01]
RuleType=Process
Target=notepad.exe
DarkModeEnabled=True
ChangeBorderColor=True
ChangeTitleBarColor=False
ChangeTitleBarTextColor=False
ChangeCornerPreference=False
ChangeTitleBarBackdrop=True
[CustomRules02]
RuleType=Process
Target=cmd.exe
DarkModeEnabled=True
ChangeBorderColor=True
ChangeTitleBarColor=False
ChangeTitleBarTextColor=False
ChangeCornerPreference=False
ChangeTitleBarBackdrop=True
[CustomRules03]
RuleType=Class
Target=CASCADIA_HOSTING_WINDOW_CLASS
DarkModeEnabled=True
ChangeBorderColor=True
ChangeTitleBarColor=False
ChangeTitleBarTextColor=False
ChangeCornerPreference=False
ChangeTitleBarBackdrop=True

 

For multiple sections, I assume I would have to use something like IniReadSectionNames and then determine which ones start with CustomRules* and parse into array.

For single section, it would be something like:

Spoiler

[CustomRules]
RuleType=Process
Target=notepad.exe
DarkModeEnabled=True
ChangeBorderColor=True
ChangeTitleBarColor=False
ChangeTitleBarTextColor=False
ChangeCornerPreference=False
ChangeTitleBarBackdrop=True
RuleType=Process
Target=cmd.exe
DarkModeEnabled=True
ChangeBorderColor=True
ChangeTitleBarColor=False
ChangeTitleBarTextColor=False
ChangeCornerPreference=False
ChangeTitleBarBackdrop=True
RuleType=Class
Target=CASCADIA_HOSTING_WINDOW_CLASS
DarkModeEnabled=True
ChangeBorderColor=True
ChangeTitleBarColor=False
ChangeTitleBarTextColor=False
ChangeCornerPreference=False
ChangeTitleBarBackdrop=True

 

And I would need to split those properly to get into an array. Something like total lines in the array divided by however many rule lines are in each ruleset.

This is where I left off this morning trying to determine which made more sense and which was easier for myself (or that person who may be writing GUI) to modify the custom rules.

If I stick with this INI config type, what would be the best way to organize and store these rules in the INI file?

[WildByDesign]

Ultimately, my end goal is to load all of the custom per-app and per-class rules into a single array that will take priority over the global rules.

Example:

RuleType would either be Process or Class. This is just an example, so the total number of rows or row contents will probably be slightly different once I implement the function(s).

[argumentum]

42 minutes ago, WildByDesign said:

If I stick with this INI config type, what would be the best way to organize and store these rules in the INI file?

It can be explicit: each rule is defined, or differential: just declare the values that will be different from default.

42 minutes ago, WildByDesign said:

For multiple sections, I assume I would have to use something like IniReadSectionNames and then determine which ones start with CustomRules* and parse into array.

Don't forget that eventually you'll make a GUI for the settings so, add a "RuleName=My Houes MyRules For This"
And even tho 2 digit is enough, I'd make it 3 digit ( Rule_001 ) to make it more... better  

2 minutes ago, WildByDesign said:

Ultimately, my end goal is to load all of the custom per-app and per-class rules into a single array that will take priority over the global rules.

Since you're gonna read the ini, you'll manually do the transpose.

Looks good  

[argumentum]

51 minutes ago, WildByDesign said:

Target=notepad.exe

4 minutes ago, argumentum said:

"RuleName=My Houes MyRules For This"

..yes, that was nonsense   

[WildByDesign]

25 minutes ago, argumentum said:

It can be explicit: each rule is defined, or differential: just declare the values that will be different from default

That’s a very good point. I will have to keep that in mind for the function too.

26 minutes ago, argumentum said:

And even tho 2 digit is enough, I'd make it 3 digit ( Rule_001 ) to make it more... better

Good point also, that makes sense.

27 minutes ago, argumentum said:

Don't forget that eventually you'll make a GUI

I wanted to hold off on the GUI until the features are all ready. That seems ready now for the most part. 

I had someone express interest in creating a GUI for it using DirectUI and this person makes really beautiful GUIs which would respond perfectly with this as like an engine for it. But I haven’t heard back in a few weeks now and not sure how long I want to wait.

But on the other hand, I don’t enjoy making the GUI too much. Autoit lacks ability to make transparent combo box which would be nice with this. Although I can do transparent buttons and input/edit boxes. No luck with combo though.