Default UI for Windows apps should be WinUI, not Win32

[paulo-assoc]

Win32 is for old, classic desktop applications.

• More boxy and flat.
• Controls have less or no animation.
• Scrollbars, buttons, and menus look traditional and sometimes inconsistent across apps.
• UI elements often reflect Windows 7-era design, even on Windows 11.
• High DPI support can be inconsistent unless manually handled.

WinUI is the go-forward UI Library for modern Windows apps. It uses the Fluent Design System (same design language as modern Windows 11 apps).

• Rounded corners
• Acrylic / Mica materials
• Smooth animations
• Modern typography
• Controls match the look of Settings, Photos, and other modern Windows apps.
• High DPI and scaling are handled automatically and look crisp.

Perry could depend on Windows Reactor, which is a UI library for Rust developers targeting WinUI. Take a look at this repo: https://github.com/microsoft/windows-rs

IMHO, there is no need to support Windows 7 and Windows 8 / 8.1, which have a tiny market share and are not even supported by Microsoft. XAML islands are a kludge.

WinUI apps are the closest to iOS and Android apps in cross-platform look and feel. Please consider.

Below is screenshot of the Perry ToDo app compiled for Windows using Win32 -- The UI style looks forty years old:

[proggeramlug]

Thanks for the detailed writeup and the screenshot — the critique is fair. The Windows backend (crates/perry-ui-windows, ~22k LOC) is today entirely Win32/GDI, with WebView2 as the only modern rendering surface, and several of the styling paths that would modernize it (border/opacity/shadow, corner radius) are still stub-with-state. So yes, out of the box it looks dated.

A couple of clarifications and where we're landing:

On windows-rs / "Windows Reactor": microsoft/windows-rs is the Rust metadata-projection crate (we already depend on it — windows = "0.58"), not a UI framework. WinUI 3 from Rust means driving WinAppSDK + XAML through the WinRT projections. That's very doable, but it pulls in the WinAppSDK runtime + an MSIX/bootstrapper packaging story, which is at odds with Perry's "compile to a single native .exe" model. So WinUI won't be the unconditional default — it'll ship as an opt-in --target windows-winui backend alongside the existing Win32 one (the same way we have multiple Apple targets). That gives Fluent/Mica/Acrylic where you want it without forcing a runtime dependency on every Windows build.

In the meantime, a lot of the "40-year-old" look is fixable on the current Win32 path with no new backend: DWM Mica + rounded corners + dark titlebar (DwmSetWindowAttribute / DWMWA_SYSTEMBACKDROP_TYPE / DWMWA_WINDOW_CORNER_PREFERENCE), finishing the border/opacity/shadow apply paths, and tightening per-monitor-v2 DPI scaling. Those land first.

I've opened tracking issues for both tiers (linked below). Agreed on dropping Win7/8.x as a target floor and skipping XAML Islands. Appreciate the push here.

[proggeramlug]

Tracking issues:

• Add opt-in WinUI 3 (Fluent) Windows target: --target windows-winui #4680 — opt-in WinUI 3 (Fluent) target --target windows-winui (the go-forward backend)
• Win32 backend Fluent polish: DWM Mica/rounded-corners/dark titlebar + finish styling stubs + DPI #4681 — near-term Win32 polish: DWM Mica/rounded-corners/dark titlebar + finish styling stubs + DPI