WinFX Effect

Brian in Opinion | 8 Comments October 1, 2004

When I came back from vacation all hell had broken loose. You see, a few days before I came back, Microsoft decided that WinFX, or at least the bits that remained after the latest round of Longhorn cuts, would also be supported on downlevel platforms. To a guy deeply entrenched in the development of Windows Forms, this is fairly impactful news as a key part of WinFX is Avalon.

Not that the news wasn’t welcome. I’d been lobbying the powers that be for months that this is the right thing for customers. People buy Windows because of the apps they can run on Windows. Developers write apps for Windows because it is the most pervasive platform so they get the broadest reach. Producing a brand-new API and only exposing it on a version of Windows that no one has does not encourage developers to spend valuable time writing apps for it, especially if they can write to an existing API and support both the old and new operating systems.

It’s interesting to think that someone from the Windows Forms team would want Avalon to come down level. That muddies the waters quite a bit, doesn’t it? Mike Harsh’s post underscores what a lot of us on the Windows Forms team have been thinking: are we working on dead technology? Or more to the point, why would people want to code against Avalon instead of Windows Forms?

The answer is different depending on which kind of developer you’re talking to. If you’re talking to an application developer whose primary job is to combine existing controls from the toolbox into an application, then that developer probably doesn’t give much of a hoo-ha whether she uses Avalon or Windows Forms provided they have similar development experiences. The differences are purely technological, hidden away under the covers. Those developers will continue to happily use Windows Forms until cool controls cease to exist for it some time in the far far future.

If, on the other hand, you’re a control vendor creating controls to put on that toolbox you care a great deal. You want an API that doesn’t come between you and control nirvana. Here is where Windows Forms starts to lose a bit of its luster. Windows Forms is built on Win32. For many of us, that’s a good thing. We grew up with the Petzold book and Win32 is comfortable to us. But even those of us who work deep in message routing and GDI every day have trouble implementing controls. Why? Because Win32 is showing its age. The user interfaces elements found on modern applications couldn’t have even been imagined when Win32 was first designed. Do you know how many people in the Office team work on creating those coveted Office-style toolbars? Lots. More than some software companies have on their entire development staff.

Windows Forms gives Win32 a lot of enhanced abilities. Our own office style toolbars – ToolStrips – were written by only two (very capable and obsessive) developers. Those developers were able to leverage richer layouts, GDI+ rendering, and managed code to do what would have otherwise required an army. The Office team was not impressed. But those two developers will tell you that it was still quite a lot of work, tweaking pixels here and there, inventing a lightweight element model for the items in a toolstrip, allowing large controls to be composited inside those lighter elements, even implementing a proper pop-up window so focus stays where you want it and your application title bar stays the right color was a challenge.

That is where Avalon excels: it is a technology that takes more of the complexity out of doing complex tasks. It’s not revolutionary, its evolutionary. And, it’s sorely needed. It’s needed by control developers everywhere so they can create controls with great usability without hiring an army of Win32 experts. It’s needed by end users because they deserve to have great usability in all their applications, not just the ones that Microsoft threw a bazillion dollars at.

It’s important to cut through the marketing hype and recognize Avalon for what it is: a modern day compositing and rendering engine. Sure, it can do dancing hippos. So can the web, but thankfully we moved past that. It’s also important to realize that from an application developer’s perspective, there is little difference between Avalon and Windows Forms. For years there will be interesting controls built from both technologies. I wouldn’t be surprised if there were even controls that were simultaneously built from both technologies, say selling as a Windows Forms control but rendering internally using Avalon. It will be crucial that Microsoft allow developers to mix and match between these two technologies for as long as it makes sense. Personally, I’m looking forward to it.

 

Comments (8) -

RichB, Friday, October 1, 2004 at 10:24 AM

Can you please add the lightweight popup (aka Raymond Chen's fakemenu) to Whidbey?
I spent a few hours once trying to port the PlatformSDK sample to Everett and almost got there - but it was very unreliable.

Paul Colton, Friday, October 1, 2004 at 11:33 AM

You can use XAML on all .NET 1.1 platforms for WinForms development today with Xamlon. Not only will this allow you to 'mix and match' today, but the code will work unmodified on Longhorn.

Brian Pepin, Friday, October 1, 2004 at 4:27 PM

Rich --
We can meet you half way Smile.  ToolStrips seem to be the new hotness in everything.  ToolStripDropDown does a full pop-up window.  It's public, and it doesn't have to contain toolstrip items so you can put whatever you like on it.  The designer task popup windows that the Windows Forms designer uses inside of VS 2005 use this to implement popups.

Brian Pepin, Friday, October 1, 2004 at 4:28 PM

Paul --
You're absolutely right.  Xamlon rocks.  You should write a package for VS that would allow it to work with the Windows Forms designer...

Paul Colton, Friday, October 1, 2004 at 7:52 PM

Brian --
We already have!!! Check out this video and you can see it in action (last of the 3 demos): http://www.xamlon.com/movies/demo/

Stephane Rodriguez, Friday, October 1, 2004 at 10:56 PM

You have a chance now to regain credibility by showing an Avalon control IDE. Don't lose it.

Brian Pepin, Saturday, October 2, 2004 at 4:09 PM

Paul -- Wow, I haven't looked at xamlon in a while.  That stuff looks great.
Stephanne -- Thanks.  We do intend to take that chance Smile

Frank Hileman, Sunday, October 3, 2004 at 11:34 AM

I don't think people will want to write controls targeting Avalon just to draw things. The API is huge, and will require some kind of large download on the part of the end user. The VG.net vector graphics runtime is only 340K, can be xcopied to the client, runs in Internet Explorer with the default security settings, has only vector graphics designer integrated in Visual Studio .NET, and is the only fully optimized, fast vector graphics system for windows forms developers.
Comments are closed