Shawn Burke's Blog : Controls

WPF and Silverlight Toolkit Compatibility

sburke — Tue, 11 Nov 2008 22:50:47 GMT

General Compat Thoughts

The majority of the controls in the Silverlight Toolkit November 2008 (PDC) release are Silverlight versions of controls already present in WPF.

These "WPF Parity" controls include:

DockPanel
WrapPanel
ViewBox
Label
Expander
TreeView
HeaderedContentControl
HeaderedItemsControl

We focused heavily on API compatibility for these controls, only making changes (I'm actually not sure if there were any) for things that aren't currently possible on the Silverlight 2 runtime. And some things, like supporting Visual State Manager, required internal changes that made the process more complicated than just copying the existing WPF code.

We did leverage the WPF control specs and use the WPF controls behavior as our guidelines, and we were pretty hard-core about making sure the Silverlight Toolkit control's API was a strict subset of the corresponding WPF control's API. One of the primary compatibility goals was also to enable sharing of design assets, via VSM between WPF and Silverlight with minimal changes, and this enables that as well.

Even so, the controls aren't "strictly" compatible for two main reasons:

CLR Namespace: All of the Silverlight Toolkit controls are in the Microsoft.* namespace instead of the System.* namespace. We made this change for a variety of reasons, some of which I mentioned in a prior post. Basically we want our "out-of-band" controls to be in "Microsoft.*" and the platform ones (e.g. in the core runtime) to be "System.*". The main benefit of this is that when/if we decide to move controls into the runtime they will NEVER collide with the existing ones and therefore won't break any applications. This then is an opt-in model for developers for when they want to swap over to the runtime controls
XML Namespace: Silverlight doesn't currently support the same XML namespace semantics that WPF does. In WPF you can use the XmlnsDefinitionAttribute to "collapse" multiple CLR namespaces into a single XML namespace. Silverlight's parser doesn't currently support this, hence the need to have a separate XML namespace for each CLR Namespace + Assembly pairing, and you need to have a prefix for that in your XAML.

The upshot of all of this is that, to move your code from Silverlight to WPF, for the "parity" controls listed above, you'll need to do two things:

Change your using/Imports* clause to be System.Windows.Controls from Microsoft.Windows.Controls.
Remove the xmlns declaration and the prefixes from the XAML. So <controls:DockPanel /> becomes <DockPanel/>, for example.

The constraints outlined above made it difficult to make compat "Just Work" at this point in time. Doing so would have required a set of complex tooling changes and too many "moving parts" that could result in broken applications or versioning issues. As such, our main goal was to make this compatibility experience simple, consistent, understandable, and something the compiler can help you with. All of which tend to be my preferences in most cases. It's much easier for us to implement and deliver, while being easy for developers to manage. At some point we may add some help to automate this if developers do have trouble with it.

How Compat Affects The Silverlight Toolkit

Which brings me to the point of all of this.

Looking at the CodePlex IssueTracker, there are quite a few issues reported that are more feature requests than bugs. Unfortunately, many of these are things that we can't do without affecting the "subset" compat that I mentioned below.

For example, there are several of these relating to the the TreeView:

TreeView: Drag & Drop, Inline Node Editing

TreeView: Ability to Cancel TreeViewItem Selection

TreeView: Showing Connecting Lines in TreeView

We are having some conversations about how to handle this. The optimal solution would be for us to be able to have a derived TreeView class that does all this stuff, that we can then port back over to WPF so the same "extended" functionality works there. Another option would be to write a separate "TreeViewEx" that does this, but that brings with it the potential for a lot of confusion and duplication. And in both cases, we're investigating how many of these modifications can coexist peacefully. We're still investigating.

In any case, this is an area where we're happy to take feedback on or any other ideas about how best to handle this.

* when controls move from the Toolkit such that a control exists in both places for some amount of time you may need to do an explicit "using DockPanel = System.Windows.Controls.DockPanel;" disambiguation.

Silverlight Toolkit Now Available For Download

sburke — Tue, 28 Oct 2008 12:00:00 GMT

On the heels of Scott Guthtrie's PDC keynote this morning, I'm very pleased to announce the launch of the Silverlight Toolkit on CodePlex!

The Silverlight Toolkit is a collection of components dedicated to making you - the Silverlight Developer - as productive as possible writing Silverlight. The full Silverlight Toolkit is available under the Microsoft Public License, an OSI-Approved license that allows full reuse of the code.

If you've read my last few posts, you know we're doing a slightly different release model. Based on what we learned with the AJAX Control Toolkit, Scott asked me to build a team focused on writing controls for Silverlight and WPF that could do so in a rapid, agile way. The Silverlight Toolkit is the first delivery from that team.

Download it here.

Release Model

We are focused on a rapid, feedback-centric release model. Our goal is to update the Silverlight Toolkit releases roughly every 6-8 weeks - gated mostly on when we have "critical mass" of features or functionality. Each release may contain new components, bug fixes, or both.

We've delivered the Silverlight Toolkit as a set of assemblies, instead of just one. We wanted to make sure that Silverlight Applications can pick the components they need and not pay to download all the ones they don't. So we looked at all the components we're releasing today, and some that we're considering in the future and came up with some high level "buckets" that are easy to remember and give us room to grow. Each of these buckets represent an Assembly in the Silverlight Toolkit.

Common - the Silverlight Toolkit base classes and components that we think a large percentage of applications will be using. This contains AutoCompleteBox and the layout controls. Default prefix is "controls".
Input - components that take user input. For this release, only NumericUpDown and it's base classes are in here. Default prefix is "input".
DataVisualization - this contains the charting components. Default prefix "charting".
Layout, Media - these are DLLs (buckets) that don't have any components for this release, but expect to see them in the future.

Quality Bands

There are two different ways that you can do software releases. The traditional way is to hold an entire release until all components reach, roughly, the same quality level. This works fine but forces all of your users to wait for everything. It's a bit of an agility buzz kill. Another method, is to have a single, rolling, release vehicle which has components different quality levels. This works fine, provided you can clearly designate which components are at which level so users can make informed decisions about what they are using.

Enter Quality Bands, which are high-level buckets that describe a given components API stability and overall finish level. This concept ties in with the Issue Tracker on the CodePlex site. Users file and vote on bugs, and we continue to improve the component in response to that feedback. It's the nature and the volume of that feedback that helps us determine when to move a component to the next band. As you move up the Quality Band scale, you'll get components that are mode dependable for a wide variety of projects.

What are the Quality Bands? We've designated four of them:

Experimental - components that are added to garner scenario or usefulness feedback. These may not have a future in the Silverlight Toolkit.

Preview - these are components that we have made a commitment too and we think will work for ~80% of the major scenarios. Many components are relatively simple and if you just need the basic functionality, these may work for you. We always do our best to minimize "breaking changes" in APIs or behavior, but components at this band may see some level of this as we perfect the API. Think of this as Alpha quality, give-or-take.

Stable - these components have moved out of Preview and should handle 90+% of scenarios. We'll hold any breaking changes to a higher bar but if something is really wrong, we'll change it. Something like Beta quality.

Mature - these components are at full "RTM" quality and fit-and-finish. These components will not have breaking changes (except in rare critical situations like security issues) and are usable in a broad range of scenarios. The API stability is key here - by using these components, our goal is that upgrading from one Silverlight Toolkit release to another should be a no-brainer.

The Silverlight Toolkit contains a CHM help file, and if you navigate to any of the component's documentation, you'll see the Quality Band clearly marked at the top. On the CodePlex site, we've also added information about this.

Controls in the Mature band are eligible to be released with the Visual Studio Tools for Silverlight package, or in the Silverlight Runtime itself if appropriate.

As you'll see below, all of the components in the Silverlight Toolkit are in the Preview or Stable bands, as this is a Preview release. And, because we haven't taken any feedback from the community, nothing can be in Stable or Mature, by definition. We're hopeful we can quickly move many of these components up through the bands!

New Silverlight Controls and Components

We have a great set of components available. You may have noticed from the image above that Charting has made it into the Silverlight Toolkit! The team has been working literally 24-hours a day to get charting into this release. We've been very focused on getting the right charting architecture and API model in place, at the cost of some more flashy scenarios. We're now confident that we are in a place where we have made the right decisions and we'll be able to quickly add chart types and animations. What sets our charts apart is that they fully take advantage of the powerful styling and templating model that's present in Silverlight.

Not only do we support templating (your truly made the template above, believe it or not!), but we do support dynamic update. If the chart above is attached to an ObservableCollection-based data source, you'll see the bars animate as your data changes. It's very cool (UPDATE: example animation here at Tim's blog).

AutoCompleteBox is a great component as well. It allows full templating as well as super-easy "out of the box" scenarios where you just attach it to a collection of items. It's very flexible. Check out this AutoCompleteBox with a DataGrid as the drop down:

This sample searches all columns with the word "New".

Of course there is more, and here's the full list of components and their Quality Bands.

Components in the Preview Quality Band
- AutoCompleteBox
- NumericUpDown
- Viewbox
- Expander
- ImplicitStyleManager
- Charting

Components in the Stable Quality Band
- TreeView
- DockPanel
- WrapPanel
- Label
- HeaderedContentControl
- HeaderedItemsControl

Theming Containers

Another major goal of the Silverlight Toolkit is to help developers build good looking applications on this great Silverlight platform. So in this release you'll see six new themes that you can use in your application. We will also be making these themes available on WPF.

Silverlight lacks a WPF feature known as "implicit styling", which allows the theme for a type of component - say, Button - to be defined centrally. One of the powerful attributes of the Silverlight Toolkit is that it allows us to deliver "stopgap" functionality to help developers outside of the main Silverlight ship-cycle. In this release, we have a component called Implicit Style Manager (ISM) that allows to do this in a way that is similar to WPF.

We're leveraging ISM to deliver these themes in a very simple way. Each theme is available in raw XAML, or in a DLL. In this DLL, is the theme and a "theme container". For using it, just add a reference to the theme DLL to your project, then wrap your UI with that container. Done!

Before:

XAML:

After:

<shiny:ShinyBlueTheme>
<StackPanel Margin="10" >
<Button Content="Button"/>

<CheckBox Content="CheckBox"/>
<RadioButton Content="One"/>
<RadioButton Content="Two"/>
<basics:Calendar/>
</StackPanel>
</shiny:ShinyBlueTheme>

There's lots more. With the Silverlight Toolkit project, we've got a great sample site that shows all of the components and how to use them, and we've got more components and themes on the way! This site is also hosted on Silverlight.net here.

Note at the top you can see the running sample, the XAML, and the C# code it took to build it. Play around with it - there's lots to do there.

Information and Support

There are several ways to get support on the Silverlight Toolkit:

File bugs on the CodePlex Issue Tracker.
Ask questions on the Silverlight Controls Forum.
Check out all of the blogs and materials available from the Silverlight Toolkit team and others like Jesse Liberty's Silverlight Geek and Tim Heuer's blog.

I hope this has given you an idea of what we've been up to and where we are headed. Let us know what you think!

Silverlight 2 Released - Silverlight Toolkit on the Way

sburke — Tue, 14 Oct 2008 20:32:17 GMT

As you know, today we released Silverlight 2. Scott mentioned the Silverlight Toolkit in his post as well - which is exactly what my team is working on. We're driving hard to get the first preview release of the Silverlight Toolkit at PDC later this month.

Just to reiterate a few points that Scott called out. We'll be doing the release under an OSI license (MS-PL) and we will again be including unit tests and a testing harness. The harness is something that you're welcome to use in your projects, I talked about it a few weeks ago. We're including the tests themselves so that developers will be able to have plenty of examples about how to write tests, but also it allows some level of coverage for any modifications users choose to make to the controls themselves.

Keep watching this blog for updates on the Silverlight Toolkit and how we're progressing. In the meantime, here's a screen shot of just a few of the controls in action, with different themes applied.

(No, we're not doing an Outlook control...that's just example content.)

Lots more to come.

Unit testing with Silverlight

sburke — Tue, 30 Sep 2008 22:57:19 GMT

One of the things I was most excited about when we shipped the Silverlight 2 Beta 1 controls was the included unit testing harness, written by Jeff Wilcox. I think it's a good thing when we can share some of our internal tooling. It's good for customers, because they can leverage the work that we've been doing, and it's good for people here because it gives them a chance to "ship" something and get some visibility in the industry. And this is definitely the case with the Silverlight Unit Test Framework, which Jeff has just updated for RC0.

This is the exact package that we're using internally to run our automated unit tests and we've been adding features to it as our team grows. Oftentimes, development teams here at Microsoft use a different testing harness from what the testing teams use (please don't ask...) and I'm keen to avoid that setup, and the Silverlight Unit Test Framework provides the functionality for both. And that we're allowing customers to leverage it opens up some other possibilities that I'll get into later. Note that the Silverlight Unit Test Framework is an unsupported toolset, not an official Microsoft product.

Some of you may be asking why we wrote our own unit testing harness instead of using something like nUnit or MbUnit. The main reason is because the existing offerings were all written against the full .NET Framework. Even though Silverlight is .NET code, it really is a different platform. And it has some special needs due to the constraints on the type of reflection you can use (public only) and how you're able to instantiate and discover tests. So we decided we needed a harness that was written fully in Silverlight and hosted the tests directly in the harness itself. This has worked out well.

So if you're starting to get rolling with Silverlight, and you want to do some unit testing, definitely give the Silverlight Unit Test Framework a look.

More details here.

Updated ExpandoHeaderControl sample for RC0

sburke — Mon, 29 Sep 2008 00:14:00 GMT

Here is the updated control sample for RC0.

Just a few changes from Beta 2 - RCO:

generic.xaml needs to now be in a folder called "themes" (case sensitive) rather than in the root of your project.
In VSM transition declarations "Duration" has been renamed to "GeneratedDuration"

So porting was easy. If you want to play with this, definitely load it up in Blend and check out the great new VSM support as well. It make re-templating MUCH easier and I had some fun creating weird collapse effects (not included).

Control Freak.

sburke — Wed, 17 Sep 2008 07:40:33 GMT

Hmmm...no blogging lately...what has Shawn been up to?

Yes, guilty. But here's what's been going on over the past few months. Shortly after MIX07, ScottGu brought up an idea of building a larger team focused on building controls. We kicked this idea around for while as we talked about details, timelines, and goals. In April, most of these details were worked out and we hashed out a charter and some early areas of focus and deliverables.

The problem we saw was that we had a bit of a fragmented controls story. My team (the Agility Team that brought you the AJAX Control Toolkit, etc.) had been writing some controls. The core Silverlight team was writing some controls. The UIFX Team (which brought you ASP.NET and Windows Forms) was writing some controls. The WPF team was writing controls. You get the idea. So Scott asked me to build a team that would unify these various efforts, in strategy if not in implementation. And the Controls Team was born on April 28th, 2008. After reporting to Scott for a little over two years, my team and I popped down to report to Ian Ellison Taylor, GM of the WPF and Silverlight teams and veteran of all things "UI-Platform" at Microsoft for over 15 years.

Sooooo...what exactly will you be doing?

Good question. My team owns the charter for both Silverlight and WPF control development. That means doing most of the engineering, planning, and development of controls. But it also means figuring out other ways to get controls into the toolbox for developers to use. For example, if another team is developing a control that might be generally useful, we'll try to figure out a way to get it into our deliverable.

The team is being built mostly from scratch. So while we are ramping up and getting people hired in, we're focusing primarily on Silverlight controls. Meanwhile, I have been working with the WPF folks helping them get some controls delivered to - the first of which is the DataGrid now available via the WPFToolkit. I am definitely committed to improving the controls story on WPF as well.

One of the reasons Scott asked me to build this team is to continue the work we've been doing around pioneering transparency and agility in our software development process here at Microsoft. The open model of the AJAX Control Toolkit really broke a lot of new ground, and we continued some of that with the Silverlight 2 Beta 1 Controls we did when we shipped not only buildable source, but our unit testing harness, and tests too!

Who is on this team you speak of?

All Stars. Some of them you may already be familiar with.

David Anson, Ted Glaza, Jeff Wilcox, Ning Zhang, Mehdi Slaoui Andaloussi, Beatriz Stollnitz (Costa), Justin-Josef Angel, Jafar Husain, Shawn Oster, Keith Smith, and just this week, Ruurd Boeke.

That's some horsepower right there, I tell you what. I really couldn't ask for better people, and we've got more to hire!

What about the AJAX Control Toolkit?

The AJAX Control Toolkit is in good hands. We've transferred ownership over to the ASP.NET team, and Bertrand is leading the effort. They've already started making good progress and I'm very excited about what they're planning for the future.

Okay, so when will you be shipping something?

Right. Good question. We are currently working on a set of controls for a preview release at PDC 2008 in late October. This will be a preview release, but we feel good about the quality bar that we think we can hit nonetheless. Because we're using a slight different development model, our controls will be released earlier, improve evolutionarily over time, so there isn't a clear "RTM" date for them. But in any case, we're doing a preview at PDC.

Here's a list of the Silverlight controls we are currently working on that we think will be ready. We are working on some other components as well, but I'm leaving them off the list until we have higher-confidence about them being ready:

DockPanel
WrapPanel
ViewBox
Label
HeaderedContentControl
Expander
TreeView
NumericUpDown
AutoComplete
Accordion

All of these controls will use the new Visual State Manager templating model and be fully customizable in XAML by hand or through Expression Blend. They will also ship with full, buildable source, unit tests, and an updated unit testing harness nicely wrapped up with a tasty OSI-Approved MS-PL license.

Wait as second...what's this 'slightly different' model?

Another good question. Part of it, as noted above, is that we're going to be aggressive about shipping early and shipping source. We'll be leveraging many of the learnings from the AJAX Control Toolkit as well as the SL2 B1 Controls efforts.

Basically, it is based on an iterative, customer-centric delivery model that focuses on driving out the most critical customer issues over time.

Sometime between now and PDC, we will be launching a CodePlex project for our Silverlight components (as a sibling of the WPF project mentioned above).

Here's how it works:

When a new component reaches "80%" quality - that is it meets the scenario needs of ~80% of customers - it will be added to the project.
The project will have frequent releases when there is a critical mass of customer value (say, bug fixes or new components) that justifies a release. Think every 6-8 weeks or so.
Each release will include the components, documentation, sample code, and unit tests. You, as the user are free to modify, copy, or redistribute the components however you see fit.
Customers will file bugs/issues with the components via the CodePlex Issue Tracker. Issue Tracker has a great voting facility built in. We will prioritize our bug fixing and/or enhancement work based heavily on this voting. Highly voted-for issues get fixed first, with some discretion based on cost/complexity. For example, if the #2, #3, and #4 issues are easy fixes, they may get done ahead of a complex and difficult #1 issue, for a particular release.
A given component, over time, will reach a very high quality level. Throughout this process, two things will happen. First, the "bar" for fixing a bug will go up. That means, as the component stabilizes, we will be more-and-more careful about which fixes we accept. Second, and as a corollary to the first, as the component stabilizes, we will be enforcing a stricter-and-stricter bar with respect to breaking changes. This will happen pretty quickly. A component that is "new" may have some amount of API changes as we react to feedback. But after a release or two, we will lock down the API and behavior so that these components are very stable and easy for users to upgrade as new releases come out. This is critical. We're working on a way of marking (think metadata attributes and docs) each component to call out which "stage" it's in, but the goal is to get them API stable relatively quickly. Because we do frequent releases, upgrading to each new release has to be a "no-brainer".
For all new components, goto (1)

So over time you have a rolling release that is getting more and more featureful. I don't know if 'featureful' is a word but if it's not, I'm coining it as a term right here! Anyway, you get the idea. If you want just the "baked" stuff, you can stick to the mature components. If you have a need for another newer component, you can use those too. It's up to you.

Over time, you will see some (maybe many) of these components work their way into either the Silverlight Core, or the Silverlight SDK as fully-supported components like you are used to. That's the beauty of this model - it offers quick delivery at the front end for more cutting-edge customers, and the traditional "I got it with VS" model for customers that prefer that.

When we start focusing on WPF components in the future, we'll be following a very similar model. Just replace "Silverlight Core/SDK" with ".NET Framework" and you'll get the idea.

In contrast to the AJAX Control Toolkit, we will *not* be accepting any customer contributions of fixes into the code base.

So that's what I've been up to. It's very exciting, stay tuned for more details!