Sign In
Tales from the Smart Client
John Gossman's observations on Avalon development
Translate This Page
Translate this page
Powered by
Microsoft® Translator
Options
Blog Home
Email Blog Author
Share this
RSS for posts
Atom
RSS for comments
Search
Advanced search options...
Search In:
Everything
Blogs
Forums
People
Groups
Places
Pages
Date range:
All Time
Last Year
Last 6 Months
Last 3 Months
Last Month
Last Week
Last Two Days
Tags
No tags have been created or used yet.
Archive
Archives
January 2009
(1)
November 2008
(1)
October 2008
(1)
August 2008
(2)
July 2008
(2)
June 2008
(1)
May 2008
(8)
February 2008
(2)
May 2007
(1)
November 2006
(1)
October 2006
(1)
September 2006
(1)
August 2006
(1)
April 2006
(2)
March 2006
(5)
February 2006
(6)
January 2006
(2)
October 2005
(16)
September 2005
(7)
August 2005
(4)
July 2005
(3)
June 2005
(2)
May 2005
(11)
April 2005
(8)
March 2005
(11)
February 2005
(4)
January 2005
(20)
October 2004
(12)
September 2004
(7)
The All-Avalon, All-the-time Application
MSDN Blogs
>
Tales from the Smart Client
>
The All-Avalon, All-the-time Application
The All-Avalon, All-the-time Application
Rate This
JohnGossman
26 Sep 2005 4:15 AM
Comments
4
Expression Interactive Designer (aka Sparkle) is a 100% .NET, managed code application. The source is currently more than 1200 .cs files and about 140 .xaml files totally 210,000 some lines of C# and 23,000 some lines of XAML. There is no unmanaged code directly in the Sparkle source, and only one PInvoke. The single PInvoke is used to call out to HtmlHelp. We could have used the managed wrapper for HtmlHelp, but that is in the WinForms assemblies, and since we are so Avalon based we decided to avoid additional WinForms dependencies (frankly, for interop reasons we will probably have them anyway, but sometimes it is the thought that counts).
As I mentioned in my attempt at Sparkle history, we decided early on to build Sparkle's UI using Avalon even though Avalon was very rough and untested at the time. We almost certainly could have made faster progress using a fully functional and tested UI framework like WinForms or even using unmanaged Win32. We certainly would have avoided a huge amount of churn as we constantly fixed or rewrote our code when Avalon changed.
I recently heard that in some early review BillG said Sparkle should "be the conscience of Avalon." I wish I had heard it then, because it is a great summary of how we felt. As much as we were all committed to making our team's product succeed, we always knew Avalon was more important. We needed to look at Avalon the way the customer would when they started building their applications. Frankly, there is no artifical test or team of QA people that can match trying to build real, production code on a platform. We tried to do everything the Avalon way, and tried to use Avalon features we weren't even sure we needed. At some point somebody starting calling us "The All-Avalon, All-the-time application".
We don't cover every area of Avalon, but we hit most of them and provided a lot of feedback to the Avalon team. Which was hard...because the Avalon folks were working very, very hard and most of the time all they heard about from us were the bugs and the missing functionality.
And the gamble paid off. Sparkle works and has a very powerful, unique UI. Because we are all-managed and all-Avalon we don't have a lot of fiddly interop code. And we have some features (like the zooming UI) that would have been much harder to build on another platform, if even possible.
4 Comments
Blog - Comment List MSDN TechNet
Comments
Loading...