[BUG] SourceGit doesn't fully support Windows 11 'Snap Layouts'

[goran-w]

When hovering over an application's Maximize/Restore button (on its title bar) in Windows 11, a dropdown/popup menu of Snap Layouts should appear.

This does not currently work in SourceGit, which is using Avalonia 11.3.9 since v2025.39.

However, this feature (AvaloniaUI/Avalonia#11409, AvaloniaUI/Avalonia#17380) SHOULD be supported by Avalonia since 11.3.0.

A related feature (AvaloniaUI/Avalonia#19922) merged into master was confirmed to still work along with AvaloniaUI/Avalonia#11409 (see this comment). This feature was, backported into 11.3.9 via PR AvaloniaUI/Avalonia#20076.

Could it be that SourceGit is overriding something in the handling of main window titlebar / buttons that breaks this? (The custom Window-subclass ChromelessWindow might be a culprit here, somehow?)

---

NOTE: Basic window-snapping (when moving the window and approaching snap-zones at screen edges) works fine, sort-of, but there's actually another bug found there:

• If the SourceGit main window is moved to approach a neighboring (multi-)monitor wich has a different screen resolution and DPI / scaling, the window gets resized / rescaled (to fit the other monitor's resolution) when more than half of the window is already on that other monitor's screen. So far, so good - but when moving even closer to the first monitor's edge, if the mouse pointer enters a snap zone and we release it there, the window (after being correctly resized / rescaled back to the resolution of the first monitor) does one of two things (which are both wrong):
  • Either (if initially smaller than the snap-zone), it gets snap-docked to the correct snap-corner but its final visible size is NOT correctly updated, leaving it in a rather strange situation where the window is visually smaller than the snap-zone! However, its (invisible) client-area still fills the whole snap-zone, which means we can't click on any window behind it (within the snap-zone area), since SourceGit still receives these clicks! (If the window is then simply minimized and restored, however, it suddenly "owns up" to fill the entire snap-zone correctly...)
  • Or (if initially larger than the snap-zone), it simply gets resized to a size smaller than the snap-zone and left "undocked" (somewhere near, but not necessarily within, the snap-zone).
• Tip: to reproduce these problematic situations, make sure to grab the main window in a position far from the monitor edge that borders another monitor, so that more than half of the window ends up on the other monitor before we enter the snap-zone. These issues only show up when combining the zone-snapping with the resize / rescale due to resolution differences - snapping without simultaneous rescaling seems to work fine!
• These issues are not seen with other applications' main windows (like Google Chrome) - they get resized / rescaled the same way but are still snap-docked correctly (regardless of being initially smaller or larger than the snap-zone).

[love-linger]

Done

[love-linger]

For multiple monitors with deferent DPIs, it is a known issue (and event exits in Window's built-in apps). I do known how to fix it. Sorry.

For multiple monitors with deferent DPIs, it is a known issue. And docking is not handled by SourceGit. On Windows, SourceGit has enable full system decorations (borders, shadows etc.)

[love-linger]

I think it is because the DPI changed event has not been triggered correctly in AvaloniaUI.

[goran-w]

Actually, I don't think the DPI issue is due to Avalonia itself, it seems to be specific to SourceGit!

I created a new "dummy" / "vanilla" application, using the steps from this page:
https://docs.avaloniaui.net/docs/get-started/getting-started

The resulting dummy-application is using Avalonia 11.3.9 and does not have the DPI/docking issue I describe above. Instead it docks correctly when dropped in the snap-zone, for both cases (smaller / larger than snap-zone), even after first being DPI-rescaled (by more than half its area being present on the neighboring monitor).

[love-linger]

Confirmed that this issue also exists in AvaloniaUI 11.3.9.

To reproduce:

• Checkout release 11.3.9
• Set ControlCatalog.Desktop as startup project
• Modify the MainWindow.xaml in ControlCatalog project
  • MinWidth = 1024 and MinHeight = 600
  • ExtendClientAreaToDecorationsHint="True"
  • ExtendClientAreaChromeHints="NoChrome"
  • Add Win32Properties.NonClientHitTestResult="Caption" property the root panel of Window (just to enable dragging window)
• Resize the window to make its bigger
• Drag the window to snap it to the bottom right corner.

Then you will see that the window shows in both screens, one is snapped to the bottom right corner with wrong DPI, and the other screen show the left parts.

[love-linger]

Clipchamp.mp4