I’ve spent some time recently looking at the Windows Presentation Foundation (WPF). WPF is part of Vista, part of .NET 3.0 and part of Silverlight.
At some level, I’m disappointed with WPF. After hearing so much about it (but ignoring it) during the last few years, I expected it to be a radical new way of writing graphical user interfaces. Instead, it seems like a slightly different way of developing Winforms applications.
With .NET 2.0, you use Visual Studio to design your Windows “forms”. Visual Studio automatically generates code for you that creates all of the visual elements (windows, buttons, list boxes, etc.) at run time. When your form’s constructor is called, it calls “InitializeComponents()” and the generated code does the rest. The Visual Studio forms editor also lets you easily attach code to different events raised by the visual components.
With WPF and .NET 3.0, you use the Expression Blend tool to design your user interface. As with the Visual Studio forms editor, Expression Blend also lets you easily attach code to handle UI events. The output of Expression Blend, however, is not code, it’s XML. When your code’s constructor is called, again, InitializeComponents is called but, this time, the function works by loading the XML and interpreting it (creating forms, buttons, list boxes, etc.) rather than by executing generated code.
At this level, the only advantage/difference of/between WPF and .NET 2.0 Winforms is the use of XML rather than generated code. Mind you, this can be a significant advantage. By managing the UI specification as data separate from code, WPF facilitates the use of skilled graphical designers to develop user interfaces. Designers can use Expression Blend to fine tune UI without worrying about unintended changes to program code.
After looking WPF further, however, I realized how it is more significant than it appears at first blush. The WPF designers have completely reimplemented the basic Windows UI elements (and more) in a much more cohesive, sensible, fashion. The net result (no pun intended) is very cool.
For 20 years now Windows programmers have been suffering the limitations of the original Windows 1.0 design from 1985. Windows 1.0 defined a basic set of UI controls: window, menu, list box, static control, text control, push button, radio button and group box (I think that’s all of them!). These controls were implemented by Windows itself and could be composited by programmers in their own applications. Additionally, programmers could subclass these controls to alter their behavior or to implement their own user-defined controols.
Subsequent versions of Windows introduced new controls. Somewhere along the line, combo boxes, context menus, rich text controls, progress bars and other controls were added. The concept of a small set of built-in controls with narrowly prescribed behavior persisted however. You could do some things like image-based pushbuttons or scrolling lists of images by taking advantage of owner draw features but the amount of customization available with the built-in controls was minimal.
.NET 1.1 and 2.0 added new controls, too, including DataGrid and DataGridView that had no built-in counterparts. These controls, however, resembled the built-in ones in how the could be used and customized.
With WPF, the original Windows UI elements are totally subsumed by the new WPF UI model. It is possible to use WPF to write what looks like a traditional Windows application, but it is also possible to write applications with much more sophisticated user interfaces.
WPF has a very clean notion of containment and transformation. Let me explain what I mean by these. Consider a traditional Windows 1.0 List control. It contains a list of strings and can present these strings in a vertical list, providing scrollbars if they are needed to view all the list contents. In WPF, the ListBox control is a container that will provide a scrolling list of whatever it contains. What can it contain? Anything! Well, any WPF UI element. If you put static text boxes in a WPF list, it’s alot like a Windows 1.0 list. But if you want, you can put editable text boxes or tree views in a WPF ListBox and it will do the right thing with them. There are several container controls in WPF and all of them support this functionality.
Similarly, WPF provides a consistent mechanism for visual transformation. In graphics (and, don’t forget, WPF has full support for 2D and 3D graphics) “transformation” refers to mathematical manipulations to modify the appearance of what is being displayed. There are translation, scaling and rotation transformations that can move, size and rotate graphical data. WPF supports these transformations, too. If you surround a text box with a 90 degree rotation transformation, the text box will appear (and function) vertically instead of horizontally. Transformations can apply to entire graphical elements (for example, our previous ListBox) or to contained elements (we could have one tree view rotated within our list of tree views).
Beyond the generalized concepts of containment and transformation, WPF also adds support for animation including keyframe animation. With keyframe animation, Expression Blend lets you specify the visual characteristics of a UI at two (or more) points in time and the WPF run-time code will take care of gradually transforming the UI for the intervening points. You can, for example, place an image at one (x,y) coordinate to start and at another (x,y) coordinate 10 seconds later. The WPF run-time code will then gradually move the image from the initial to its final location over the course of 10 seconds. Key frame animation can be applied to scaling and rotation transformations as well as to other visual effects (transparency, for example).
So far, I’ve mostly read about WPF. I want to write some non-trivial software to put it through its paces. From the design perspective, I really like it. I also like the relationship between stand-alone WPF applications and Silverlight (browser-based) applications. I’ll post again on the topic when I have more to say.