| I've concluded that Windows Forms is the least bad of the official Microsoft GUI frameworks. MFC is OK if you can accept its crufty old flavor of C++. But it wouldn't allow for much sharing of code between Windows desktop apps and modern (Metro) apps, whereas a .NET-based solution would let you share non-GUI code easily. WPF was developed for a relatively short period of time, starting in the early 2000s, and then basically abandoned. Windows Forms may not be much older than WPF, and both are apparently now in maintenance mode, but Windows Forms has the advantage of being based on the Windows API and common controls, which have been developed since Windows 1.0 in 1985. WPF was all new technology; it used the older Windows APIs only as much as it had to. So Windows Forms is based on the tried and true foundation for Windows GUIs. This is a bit fuzzy, but it seems to me that WPF reflects the rich-client excesses of its time. In the early to mid 2000s, Microsoft and Sun (with Java/Swing) were trying very hard to be better than web apps. For Microsoft with WPF, this meant building the whole framework on a very advanced graphics subsystem, the then-cutting-edge Direct3D 9. I dare say they didn't care much about running well on older or less capable hardware; they just wanted to take full advantage of what the latest hardware could offer. By contrast, the Windows GDI and USER subsystems were designed to run on primitive raster graphics hardware, so Windows Forms apps benefit from the relatively low system requirements. Now I'd like to present a case study in how the excesses of WPF resulted in a less than satisfactory user experience for a niche application where WPF's advanced graphics capabilities were almost certainly unnecessary. My brother is a Christian minister. About three years ago at Christmas time, while he was still a seminary student, he told me about how his then-current laptop wasn't serving him well any more. Among other things, he mentioned that the Logos Bible study software he used wasn't running efficiently, and that for reasons unknown to him, Logos was unusually demanding when it comes to graphics hardware. This seemed anomalous at the time; a program like Logos is little more than a text viewer and editor. I didn't dig into that at the time, though; I just bought him a new laptop. You can guess where this is going. Tonight, during my wandering about the Web, I happened to find out that starting with version 4, Logos was based on WPF. I made the connection with the conversation from three years ago, and confirmed that the excessive demands on graphics hardware were really an issue. See, for example, this forum thread from 2009: http://community.logos.com/forums/t/6200.aspx I feel bad for the users who had to take time out from their real work to post on a forum like this about technical minutiae like video card specs. At least one user justifiably questioned why a text-based research program like Logos would require a cutting-edge video card. We who develop end-user-facing software should take this as a lesson in how not to make our users happy, by prioritizing developer convenience and/or gratuitous use of cutting-edge technology over delivering a good user experience on the hardware that users actually have. |