Fixes #677 partially, though I don't see issue with button size in relation to other Fluent apps. On my 4k laptop the caption buttons look the same as Windows Explorer, for example.

For the gap next to the right of the caption buttons, it seems to be default behavior out of the box when setting a WindowChrome.

NonClientFrameEdges = NonClientFrameEdges.Right was the minimal way to fix it.

https://learn.microsoft.com/en-us/dotnet/api/system.windows.shell.nonclientframeedges?view=windowsdesktop-9.0

Setting any other single value didn't fix. Setting Top alone or with other values didn't work. And you can only set 3 at a time out of the 4. So I set Right, Bottom, and Left. I'm not sure exactly the implication but I will cite what I got from Copilot as justification why I thought might as well let OS manage as many edges as we can:

When you use WPF’s WindowChrome to customize your window, the property NonClientFrameEdges lets you decide which parts of the window’s border—the “chrome” that normally handles things like resizing, hit testing, and standard visual effects—are left in the hands of the operating system rather than being completely overwritten by your custom client code.

In a typical Windows window, there are two “areas”: the client area (where your app’s content lives) and the non-client area (which the OS owns and which handles window frame rendering, borders, caption buttons, and resizing behavior). With WindowChrome, you can extend your WPF visuals into that non-client region for a completely custom look. However, completely taking over every edge (i.e. having the client “own” all sides) means you must reimplement or work around standard behaviors like window resizing and even subtle effects (such as Aero Peek, hover animations, or the proper hit testing at the edges). By designating one or more edges with NonClientFrameEdges (choosing from values like Left, Right, Top, or Bottom), you’re telling the framework, “I want the OS’s window manager to keep handling that edge.” In other words, that edge will be rendered and function with the OS’s built‑in behavior.

On a side note, some have used setting NonClientFrameEdges to solve flickering problems that arise from using a WindowChrome. I didn't see any flickering by default with the Gallery or a new project that uses .NET 9 Fluent styles, so maybe you're already handling that but could be useful to prevent those.

dotnet/wpf#1176 (comment)

https://stackoverflow.com/questions/51669632/wpf-windowchrome-causing-flickering-on-resize/54904747#54904747

In DevExpress ThemedWindow (just as an example) they exist, because DevExpress uses a custom WindowChrome instead of the native object:

https://supportcenter.devexpress.com/ticket/details/t1201744/themedwindow-resize-behavior-when-resizing-from-the-left-border

Some complain when setting this it causes erroneous white borders or spacing but I didn't observe any.

Microsoft Reviewers: Open in CodeFlow