DwmColorBlurMica

[WildByDesign]

This script is evolving quite rapidly, therefore changes will be ongoing. This is inspired by the Great @argumentum and Win11myOwnBorderColor as much of the framework comes from that script.

Note: This is for Windows 11 build 22621+

Using that script as a basis, I have since:

• Added separate variable for title bar color
• Added the ability to change window corner preference (eg. rounded corners, square corners, etc.)
• Added the ability to extend the frame into the client area
• Added ability to apply backdrop material (eg. Mica, Acrylic, Mica Alt (Tabbed), etc.)
• Fixed child windows not having colors applied (changed to SetWinEventHook)
• TO DO list at top of script of stuff that I still need to add

At the moment, the script is running without Admin, therefore will only apply to user-mode apps. If you want to apply to all apps, remove the comment before #RequireAdmin. Eventually, I am going to add the ability to create a scheduled task (like Win11myOwnBorderColor already does).

I already have an AutoIt tray tool, so I will probably integrate this into my other tray tool. I may keep it as a separate executable which would then be run as a scheduled task.

 

Problems:

If you run into any problems with any apps, you can press Esc key to close DwmColorBlurMica and any apps that were not happy with it, simply restart them. I have excluded some apps in the script, such as Explorer and Start menu. But I still need to work on an exclusion list (and maybe inclusion list) that is either in the INI file or other file. I would like to be able to eventually load those into an array at some point.

 

Features:

• Change border color to any color
• Change title bar color to any color
• Enable dark mode app settings (particularly dark mode title bar)
• Apply backdrop material (eg. Mica, Acrylic, Mica Alt (Tabbed), etc.) to the title bar
• Applies settings to all currently running windows and new windows
• Extend title bar color and materials to client area *

* Please note that the extending of color and materials to client area (DwmExtendFrameIntoClientArea) works best with pure dark themes. For example, Rectify11's Black (Mica) theme. Also, some apps simply don't work well with it. It is a feature that really should be Opt-in per process which is something that I still need to implement.

The possibilities (especially when mixing some of these options) are almost endless. The screenshots below only show a small amount of what is possible.

 

Screenshots:

Spoiler

  

  

  

  

 

Changelog:

Spoiler

Version 0.0.3

• added process exclusion list to INI to exclude processes from all functions
• created separate function for DwmExtendFrameIntoClientArea to make it Opt-in only
• changed events to $EVENT_SYSTEM_FOREGROUND, $EVENT_OBJECT_FOCUS, $EVENT_OBJECT_CREATE
• updated INI file with process exclusion/inclusion entries

Version 0.0.2

• removed Explorer from exclusion list (we can have fun with Explorer now!)
• added exclusion rule for "Program Manager" window name so that desktop isn't modified
• added exclusion rule for blank window names which reduced CPU significantly
• added events ($EVENT_OBJECT_SHOW, $EVENT_OBJECT_FOCUS, $EVENT_SYSTEM_FOREGROUND)

 

Current script version: 0.0.3

 

 

 

DwmColorBlurMica.ini DwmColorBlurMica.au3

Edited 5 hours ago by WildByDesign
Added version 0.0.3

[WildByDesign]

Question for anybody:

If I am adding a process exclusion list and a process inclusion list to a configuration file, should I continue using the INI file or would it be better to switch to XML entirely?

I am hoping to have only one single configuration file to keep things portable. I will likely bring the process exclusion/inclusion lists into two separate arrays.

But what I don’t know is whether I should stick with the INI file or switch to XML. Any suggestions would be appreciated.

[argumentum]

Use whatever you feel comfortable with. INI, XML, JSON, ...SQLite, ...anything that you can write to and read from is good.
As far as portability, carrying 2 files or 20, is portable if it does not need a declaration. Say you keep a folder structure like, .\settings\thisfile and .\settings\thatFile, is all "portable" by definition.
IniRead(), IniWrite(), Ini* whatever is internal to AutoIt3. SQLite would require an external file ( the DLL ) but is all portable, as far as portability goes.
And you are not switching to XML given that there is no prior release version while you explore what is best for your project so, use XML if you feel comfortable with it. That's my view.

[argumentum]

..also, 
@AppDataDir Path to current user's Roaming Application Data 
@LocalAppDataDir Path to current user's Local Application Data 

So I personally use those to keep stuff at in the format of  @LocalAppDataDir & "\MyInitials(argg)\Project(awesomeness)\FilesThatAreNotExecutablesAreHere"

And I call that portable too, just because I don't use the registry. My code knows where information is centralized at. 

[WildByDesign]

I think that INI would be easier for user to modify. I just didn’t know if there were limitations to Value size.

For example, I imagine there could be something like 10-30 process names in exclusion list or inclusion list. Nothing significant. I’m not sure yet if INI can hold that in one value or not. But I will test and find out.

I was thinking of using iniread func to pull in as a string and use StringSplit func to create the array.

[argumentum]

16 minutes ago, WildByDesign said:

I imagine there could be something like 10-30 process names in exclusion list or inclusion list.

..that, ...that will take some exploring. Maybe you could exclude a class naming convention given that a programing platform is the one that will not work well with M$ definitions or those are newer or something.
In regards to users editing a file..., yes and no. The user should have a GUI that handles that. We are coders ( this is Sparta kind of thing ) and "users" are not coders so the likelihood of a regular user editing a file is remote, other than power users and even then, a GUI is a better place.

Because lazy coders ( me most of the time ) say "set this in the ini file", does not mean that that, is how users should use software  

Edited yesterday at 03:45 PM by argumentum
added link for the LOLs

[argumentum]

Just for the heck of it, this would be "a" config file

This is a configuration file, because that's the way I thought of it =D
The only the lines that start with ">" are the field
and the value/data of the field is after the first "=" from the left
Therefore
>MyNameIs=argumentum
is a declaration, anything else in this file
is just a comment.
The more the comments, the better =)

and the reader func

#include <Debug.au3>

_DebugArrayDisplay(ConfigReadingCRLF("MyFile.config.txt"), "Entry count: " & @extended) ; or watever extension we invent
Func ConfigReadingCRLF($sFile)
    Local $aArray = FileReadToArray($sFile)
    Local $iIndex = 0, $aReturn[UBound($aArray) + 1][2]
    For $n = 0 To UBound($aArray) - 1
        If StringLeft($aArray[$n], 1) <> ">" Then ContinueLoop
        If Not StringInStr($aArray[$n], "=") Then ContinueLoop
        $iIndex += 1
        $aReturn[$iIndex][0] = StringStripWS(StringTrimLeft(StringLeft($aArray[$n], StringInStr($aArray[$n], "=", 0, 1) - 1), 1), 3)
        $aReturn[$iIndex][1] = StringStripWS(StringTrimLeft($aArray[$n], StringInStr($aArray[$n], "=", 0, 1)), 3)
    Next
    ReDim $aReturn[$iIndex + 1][2]
    $aReturn[0][0] = $iIndex
    $aReturn[0][1] = "ConfigFile"
    Return SetError(0, $iIndex, $aReturn)
EndFunc

that may look strange but who cares !, is functional. Go figure, in the future coders will use this most awesome brainstorming in their code and it'll become a standard 🤪

Joke aside, use a standard or another. But know that you are not limited by standards. Admittedly, a standard is better because is known. But that is all**.

**There is this thing called computer "science" and those in it explore efficiencies and inefficiencies but I never cared much for that, unless I had to.

Spoiler

...and the ADHD took me to The Making of "She Blinded Me With Science"

 

Edited yesterday at 04:49 PM by argumentum
English

[WildByDesign]

With version 0.0.2 (updated changelog in 1st post), we can now play with Explorer:

Screenshots:

Spoiler

 

[WildByDesign]

1 hour ago, argumentum said:

that may look strange but who cares !, is functional. Go figure, in the future coders will use this most awesome brainstorming in their code and it'll become a standard 🤪

Thank you for sharing this. I will go over this later tonight and figure out the config, arrays, etc. But for now, I am worn out after smoothing out the File Explorer stuff (version 0.0.2). It's all good now but I need a break for a few hours.

[WildByDesign]

I've updated the first post with version 0.0.3.

The process exclusion list is to exclude specific processes from all functions. The process inclusion list is only for DwmExtendFrameIntoClientArea, effectively making that function Opt-in only.

• added process exclusion list to INI to exclude processes from all functions
• created separate function for DwmExtendFrameIntoClientArea to make it Opt-in only
• changed events to $EVENT_SYSTEM_FOREGROUND, $EVENT_OBJECT_FOCUS, $EVENT_OBJECT_CREATE
  • this was particularly needed for Explorer

You will need the updated INI file as well.