3 ms·
To be clear, we're focusing on the use case of a font editor, where you're mostly interacting with highly custom views, much less so with layouts composed of st
by raphlinus 7y ago
To be clear, we're focusing on the use case of a font editor, where you're mostly interacting with highly custom views, much less so with layouts composed of stock widgets.
As I said elsewhere, increasingly we're in a world where there isn't a standard set of platform UI widgets. I think that was the case when we had Cocoa on macOS, but on Windows it's a choice between MFC, WinForms, WPF, WinUI, and those are only some of the choices offered by Microsoft itself.
It's a good question, though. It's possible somebody will figure out a good way to abstract over officially supported platform UI toolkits, and if so, that might become a compelling choice. This is one reason why the main point of my blog is that we need to figure out the best approach, rather than just assuming we know what to build.
- Macha 7y agoMFC and WinForms both just abstractions over Win32. WPF was clearly targeting being indistinguishable from the old widgets and had a much better success rate than other reimplementation attempts. It's really only with UWP/WinUI that you'd notice the difference without going searching and that has received a lot of consequent complaints.
- jcelerier 7y ago> WPF was clearly targeting being indistinguishable from the old widgets we sure as hell haven't been using the same WPF apps
- Macha 7y agoPaint.NET is the one app I've used extensively that I'm aware of being a WPF app, and that's because I remember reading a dev blog about implementing aero glass when 4.0 was being developed.