Hacker News Reader

Comment by iamcalledrob | Hacker News Reader

The author is right, it's really such a mess.

The lessons I've learnt building and shipping a few a Windows apps at scale are basically:

(1) Learn Win32 and use those ancient APIs if possible, they're extraordinarily stable and you'll probably need to reach for them anyway. They're not that scary.

(2) Don't use any Microsoft-owned UI toolkit, you'll get burnt. Literally anything is better. Ideally choose a toolkit that doesn't prevent layering in Win32 tweaks on top, otherwise you'll end up hitting cases the toolkit developers didn't think of and you can't fix. You're going to need a custom WindowProc eventually. You need to have access to the underlying Win32 window lifecycle and handles.

View on HN

> "(2) Don't use any Microsoft-owned UI toolkit, you'll get burnt"

This is 100% true for all of their techs produced within the past ~20 years, but WPF and Winforms are extremely stable with no real issues.

It's so weird too because most of everything they've done in the past 20 years has basically just been incomplete remixes of WPF. If they just stuck with WPF and extended it onward, something like a UI toolkit equivalent of C#, it would 100% be the gold standard for Windows development today, and perhaps even UI development in general if they open source/standarded it.

Ahhm. At previous $DAYJOB, I inherited a WPF app written in 2012; I stumbled upon several WONTFIX bugs through the years - mostly having to do with shared memory bitmaps, having to manually call GC at times, and a host of other things.

Stable, but many issues. Stay away if you value your sanity and do anything nontrivial.

When they announced UWP I was just starting a new side project and I thought, let's check it out. I was hoping it would basically bring WPF into first class citizen territory. Instead, they made them needlessly incompatible. Like writing for both NeXT and MacOS, but on the same platform. I got discouraged right away and have really never done any significant Windows work since, which turned out to be a great move for my sanity.

the should just have updated wpf with their newer widgets and just continue to improve it and even make it cross platform. (basically what avalonia is doing)

WPF and Winforms may be stable, but they're not going to work well on a modern machine with a HiDpi monitor. Same with Win32 controls.

My take: Use Win32 for opening windows and interfacing with the OS. Use a different toolkit for actually drawing inside the windows.

Ideally a toolkit that can paint in sync with window open and resize, otherwise you'll get Electron-style window flickering. And something that supports multiple windows in a lightweight way, since you're going to want popups, menus etc. to extend outside parent window bounds

WPF scales and works perfectly with HiDPI displays, and (from what I've read) WinForms support for HiDPI has improved in recent years.

Glad to hear things are improving here. Still, the UI doesn't look very nice though ;)

With WinUI 3 I did not even manage to render PNGs correctly.

The colors were always slightly off and oversaturated, no matter what setting I used.

I migrated the app to Tauri and the PNGs of course rendered perfectly. The implementation was much easier overall.

Hypothesis: This could be due to the toolkit's handling of color profiles. You see this a lot in macOS land with images that use a Display P3 colour profile, e.g. screenshots from a Mac or iPhone.

Native toolkits are usually more advanced and tend to properly support the colour profiles and allow for wider gamut output. Whereas historically the web had poor handling and would assume sRGB, causing more "washed out" output.

I believe that the opposite was the case: WinUI does not handle color profiles correctly.

In the browser or the Windows Photos app they were looking correct, while WinUI was incorrectly oversaturated.

Reply on news.ycombinator.com