Windows Now

Drew Marsh wrote a great intro to those topics today.

I'll add a few things...Drew covers the concept of Attached Properties.  He should update the post to include examples of non-attached properties as well...

We have tried to make the fact that DependencyProperties exist pretty hidden.  I can remember ~2 years ago when you had to call .SetValue() to do much of anything.  Since then we require all properties to be normal CLR properties.  Some of those properties have DPs (Depenency Properites) under the covers which give additional services.  But to a developer, when I want to set the Background color of a button, I just do use a strongly typed property:

button1.Background = Brushes.Green;

instead of the loosely typed:

button1.SetValue(BackgroundProperty, Brushes.Green);

Anyway, we hope that most people don't need to know all the reasons for them, but DOs, DPs and Attached Properties are important Avalon concepts.

Let us know how it feels...try styles, try inheritance of properties, type programming against properties and attached properties...and then write down your thoughts...

Testers are customer advocates - and are best when they...
 know what real customers want to do with the technology/product that they are testing.

It takes a number of different disciplines to build software.  At Microsoft, 4 different categories make up most of the people on our development teams: Developers, Program Managers, Testers and Technical Writers.  (Our team also has a few designers...)

We have a few Testers from the Avalon team who are blogging: Zhanbo, Marcelo

A little while ago Zhanbo had a post about Avalon's visual tree.
Marcelo just posted about Avalon, high DPI and screen real estate

Anybody else out there yet?

Update: I totally forgot to mention Architects...kinda silly seeing that I work closely with them all...

I enjoy reading John Dowdell.  The latest thing I learned there about was Web Page Design for Designers.  As a non-designer, I had never known about Joe Gillespie's work with wpdfd.com - looks like he built a great destination.  Joe's final editorial before his retirement is an interesting read as it talks about his history with waves of new technology.

Learning of Joe's work and comments like this on my blog from Arturo Toledo make we wonder who is going to step up and be the authority on Xaml Page Design for Designers?

From XAMLs and Avalon´s real potential will only be realized when we have a graphic editor. XAML strongest users will be designers. They don´t code (some do but aint common)... they draw, drag, pull and sketch. They use a mouse or a tablet not a keyboard. This side of the story... the designer one, is what makes Avalon ENORMOUS in its potential. The techie side matters a lot too, specially right now where the infrastructure is being developed as we speak but the ultimate goal should be based on a creative / designer point of view who at the end will be the kind of user / developer exploiting Avalon / XAML capabilities.

Yes, I am graphic designer - animator ... and I can code :)

Joe please let me know if you are initerested in a copy of our latest Customer Tech Preview of Avalon & XAML...perhaps xpdfd.com can be your next passion?

Designers - What would you want to see on xpdfd.com?

I like the description that Karsten, Tim, and Arik wrote about XAML from the What's New in the "Avalon" Community Technology Preview article:

XAML. "Avalon" also introduces XAML, a markup language to declaratively represent user interface for Windows applications, improving the richness of the tools with which developers and designers can compose and repurpose UI. For Web developers, XAML provides a familiar UI description paradigm. XAML also enables the separation of UI design from the underlying code, enabling developers and designers to work more closely together.

On top of that, I thought it would be interesting to share the 7 major goals we had in mind while designing XAML.  Generally, many design decisions require balancing the different goals (as they often conflict).

Be XML

All valid XAML files must be valid XML files.  The opposite isn't always true…all XML files are not XAML files.  This is important because of the ecosystem of tools, systems, APIs and developers familiar with XML.

Describe Hierarchy of Objects in a Human Readable/Writable Way

Markup provides a concise way to represent a set of objects arranged in a hierarchy.  It is more readable and writable than programming languages.  It is the best format to represent the initial state of an object hierarchy.

Provide Page-Based Programming Model

Like DHTML + ASP.NET, XAML provides a way for you to associate programming code with the declarative markup.  We recommend people having a code behind file (.xaml.vb or .xaml.cs for example.), but also support code being directly embedded inside of a XAML file.  XAML and any .Net language can work together in this page-based programming model.  The .Net Language needs to support CodeDOM and a set of language specific MSBuild target files.  In this CTP, we support C# or Visual Basic.  We will likely add J# support by spring and we look forward to supporting other languages from Microsoft (C++ and JScript) and other companies in the future.

Be Source Code or Runtime Instructions

Sometimes XAML is treated as source code, that gets compiled into an assembly (.exe or .dll) as a combination of a binary representation and IL.  Other times, it is interesting to build XAML at a later time and interpret it at runtime.  While we love the benefits that a markup representation give developers, we prefer to deal with XAML at compile time, not run time.

Take Advantage of Strong-Typing

Objects that have a strongly-typed OM (object model) are better systems to program with.  DHTML is a system that was very string-based, and thus difficult to debug.  Systems that leverage XAML (including Avalon), get the benefit of using strings in markup, but can get compile time errors for markup or code.  XAML's default is that it must understand every tag and attribute.  HTML defaults to ignoring any mistyped element name, attribute name or attribute value.  While there is a place for this ignoring to allow for forward compatibility, we'll provide a different mechanism for this.

Be Toolable

Systems described in XAML will be creatable and consumable by a wide set of tools.  We hope to have a clear & minimal set of rules on how classes get represented in markup.  We hope to encourage an ecosystem of tools.

Be Useful for Much More than UI Definitions

While XAML will be heavily used in the vast majority of Avalon applications or documents, its uses will be many.  I'm writing a command line tool right now that uses a vocabulary of classes in a XAML file used as data to drive the application.  I'm getting the following benefits over just using XML to represent this data: 1) validation of my data file without having to write a schema and using a validating xml reader; 2) my code that needs to interact with this data, does it in a strongly typed way; Intellisense works in my code behind; 3) my system has built in extensibility, instead of being tied to specific tag names, I'm tied to a specific class (and subclassing allows others to provide other specializations of that class.) 4) etc… (When this tool is done, I plan on sharing it)

Don't Forget Why We Built XAML - Avalon!

That all being said, I believe it is important to remember that for as interesting as XAML itself may be to some, we are building a comprehensive platform with Avalon.  Some people blog excitedly about XAML…however, many of them are actually discussing the power of Avalon, not XAML.  XAML is a way to use declarative markup with a set of CLR classes.  We're investing much more R&D in the Avalon API and Avalon infrastructure than we are in the parser and markup compiler.

Some Related Previous XAML Posts

Why is XAML well-formed XML? (Rob Relyea)

XAML vs. Serialization (Chris Anderson)

MarkupCompilation: XAML, BAML, .g.cs Details (Rob Relyea)

When are IDs necessary in XAML & what about ID=“Root“? (Rob Relyea)

Is it bollixed up? (Chris Anderson)

New XAML Terminology (Rob Relyea)

Gaston Milano is a self-proclaimed “VS man” -  so he wanted a XAML Viewer that worked inside of Visual Studio Whidbey.  So he wrote one!

Screen shots look great!

(I just left a comment with my problems getting it running on Visual C# Express.  I'll have to wait until I get into work to see it on the full Visual Studio.)
Update: According to Gaston, VS Express SKUs don't allow the same “VSIP“ extensibility hooks.  I'll try it with the full Visual Studio later today.

Anybody try this yet?

Thanks Gaston!

I saw Joe Duffy's post about the Avalon CTP where he said:

“And it's compatible with the Express SKUs as well.“

Our team only tested the Avalon CTP with the Express SKUs briefly.  We found one major problem (and weren't able to fix it for this release):

the Express SKUs look for project templates and item templates in a different path than normal Visual Studio builds.

If you want to use an Express SKU, after installing one of the Visual Studio Express skus, Avalon, and then the WinFX SDK, you'll need to do the following:

Workaround: Installation of Templates by WinFX SDK for Visual C# Express:

• Default Visual C# Express install location is: C:\Program Files\Microsoft Visual Studio 8\, if you installed elsewhere, run the following command (but change the location as appropriate) in a command window:

Then, copy and paste these commands (all at once) into the same command window:

Workaround: Installation of Templates by WinFX SDK for Visual Basic Express:

• Default Visual Basic Express install location is: C:\Program Files\Microsoft Visual Studio 8\, if you installed elsewhere, run the following command (but change the location as appropriate) in a command window:

Then, copy and paste these commands (all at once) into the same command window:

First, PDC 2003.  Second, WinHec 2004. Now an Avalon Customer Tech Preview!

Three interesting links way below that I stole from http://msdn.microsoft.com/longhorn/.

First, a link to the bits for MSDN members.
Second, a link to online documentation and samples.
Third, a good overview of what is new or changed in this release.

I'm happy that this release will able to run on Windows XP (and Windows Server 2003 too).  I have this build running on my laptop with xp sp2, and it has very little impact on my daily use unless I'm building an application and running it.

Installing VS beta1, Avalon, and then WinFX SDK will give you a decent VS development experience for Avalon applications.

We have 4 project templates for Visual Basic or C# developers.
Avalon Application
Avalon Browser Application - will run in Internet Explorer by just changing a property in the .csproj or .vbproj file
Avalon Navigation Application
Avalon Control Library

In the xml editor, while editing a XAML page, you should get decent intellisense since the WinFX SDK installs a schema for Avalon class use in XAML.  Look in %programfiles%\microsoft visual studio 8\xml\schemas\ for avalon*.xsd and xaml*.xsd

No visual designer yet...  :-(

F1 Help works from C# or VisualBasic code.  In the XML Editor though, it is broken in this build.

No major XAML syntax changes in this build, but many changes to the elements and other features you can use.

Give it a try...would love to see what you can do with it...

Shipping feels good!

-Rob

"Avalon" Community Technology Preview Available The Community Technology Preview of "Avalon" can be found in the Microsoft® WinFX™ Software Development Kit (SDK), available for download by MSDN Subscribers. It contains documentation, samples, command-line compilers, and tools designed to help you develop managed-code applications and libraries using WinFX.

WinFX SDK Online The WinFX SDK for the version of WinFX that includes the Avalon class libraries and runs under Windows XP is available for your perusal online.

What's New in the "Avalon" Community Technology Preview In this article, we'll take a brief look at some of the changes that have been made to Avalon since the PDC release a year ago, and highlight some useful resources to help you further explore Avalon.

We have a bit of a mess in our processing for attributes.  First, a list of the mess, then a brief description of the fix we plan.

Attribute values in xaml can map to:

1) a Literal value
   <Balloon Color=”Red” />
We use the type converter from the type of the Color property.
I'm happy with this.

2) Star syntax.
    “*null” - sets the property to equals null.
    “*ClassName.StaticMember” - sets the property to equal the static member
    “*ClassName(PropertyName1=PropertyValue1,PropertyName2=PropertyValue2,...)” - we call this compact syntax.  it is most used for databinding - *Bind(Path=LastName), but has a few downsides - a) allows any class to be set this way (on top of the already possible property tag syntax). b) syntax doesn't solve all nesting, escaping problems.
    “*typeof(ClassName)” - set the property to equal the Type ClassName.
    “{ResourceName}” - if being set on a FrameworkElement or FrameworkContentElement, calls .SetResourceReference(); 
    I don't like the fact that the xaml parser builds in knowledge of Resources, an Avalon framework feature.

3) Event Handler Name
    <Button Click=”onclickhandler” />
I'm happy with this.

--------

We plan on changing the star syntax to something called “Computed value”. (not thrilled with the name)
We'll build one extension mechanism into the parser and allow different users of xaml to build their own extensions. 

One thing this will allow is to remove the knowledge that the xaml parser has of the Avalon framework feature - Resources.

The xaml parser lives in PresentationFramework.dll, but one of the key goals is to continue to untie it from the Avalon framework.  In version 1, we'll likely still ship it in PresentationFramework.dll, but conceptually we are designing it as if it was in WindowsBase.dll - it should define well factored extensions that are based on different CLR concepts - existing concepts when possible - new ones when necessary.  TypeConverters, IList, IDictionary, etc...

As part of this change, the flexibility that people have with compact syntax will be reduced.  Today, they can use *Bind(), *Button(), *AnyClass() in any attribute.  We'd like to restict this to a small set of classes that are explicitly in need of being set in an attribute.

I'm not going into great detail in the description of our fix because I'd prefer to be the first company to ship our design.  :-)

So once we do this work, we'll have:

1. LiteralValues - go through type converters.
2. ComputedValues - go through 1 well defined extension mechanism to support scenarios that need to be handled in attributes that map to many different Types.  Bind and ResourceReference, for example, can be used to set Height, of type Length, or to set Background, of type Brush.  We don't want to change all type converters to know about Bind and ResourceReference.
3. EventHandlers

Among other things, I (and my teammates) have spent much of the last year designing significant improvements to xaml2003 that you saw at the PDC in October 2003.  While we have spent a lot of time investing in design, we haven't implemented many of the changes yet.  As such, I hadn't wanted to do much posting yet.

I got back from vacation last week and found out that we'll continue some implementation very soon.  I'm very excited!

A few things to restart the flow of info about what we are doing...

Processes that involve Xaml & Baml

XamlLoading - process of loading xaml and creating objects.

XamlSaving - process of saving an object and all related objects to xaml.

XamlCompiling - process of creating code and a binary representation during compile time.

BamlLoading - process of loading code/binary representation during run time.

People used to throw around a bunch of terms for these things: Parsing, Serialization, etc…

Right now, we think that list is clear and well defined.

Syntax Terminology for setting properties via markup

Attribute Syntax - Setting a property with an xml attribute

    <Balloon Brush="Green" />

PropertyTag Syntax - Setting a property with a PropertyTag contained inside the ObjectTag (Balloon).  The PropertyTag denotes which property you are trying to set on the outermost ObjectTag.  The content inside the PropertyTag provides the value.

    <Balloon>

      <Balloon.Brush>

        <SolidColorBrush Color="Red" Opacity=".5" />

      </Balloon.Brush>

    </Balloon>

(Previous names - Complex syntax.  Compound syntax.)

Content Syntax - Many objects will have a property that is the ContentProperty.  For example:

    <Button>Hello</Button>

will effectively create a Button and set Button.Content="Hello".

For a long time, we've relied on IAddChild and let component authors decide what their ContentProperty was.  We're hoping to decorate types with that information and remove IAddChild from Avalon.

---

Crazy busy for the next several weeks, but I'll try to keep some things coming...

-Rob

I've seen this in several XAML examples on the root XML element and I've
seen plenty of examples without this attribute.  When is it needed and is
the value "root" special?

About IDs

First let's talk about IDs.  TheRHogue replied.  I've taken his reply as the basis for the answer below with some editing...

You use the ID property for accessing an element from you code. Generally, if you don't need to access the property in code behind you don't need to set an ID.

Technically, when the element is instantiated, the variable is given a unique name or the name you declare with ID.

For Example:

.xaml (page):
<TextBox ID="tb1"...>

.xaml.cs (codebehind):
tb1.Text=“Hello World“; // set the textbox's text property to Hello World

If the ID property was not set, you could not access the textbox element directly.
 

What about the Root element?

Several XAML pages out there have set ID=”root” on the root element of the page.  While this is fine to do if you want, you don't need to do it.  Here is why:

All code that you embed in the page or in codebehind is compiled into a new class.  This class automatically derives from the original root element you had in your page.

So in this example:

Page1.xaml
<Window>
    <Button>Go</Button>
</Window>

We build a new class that derives from Window and add all the page logic and some generated code into that class.  When you load Page1.xaml during runtime you end up with a tree like this:

<SomeSubclassOfWindow>
    <Button>Go</Button>
</SomeSubclassOfWindow>

If you'd like to name that class, you can do that:

Page1.xaml
<Window def:Class=“MyWindow“>
    <Button>Go</Button>
</Window>

You'll then end up with:

<MyWindow>
    <Button>Go</Button>
</ MyWindow>

So, in code, to refer to the root element in C# just say “this”.

this.Height = 200; //for example...

For some more details, see my January 2004 post: MarkupCompilation: XAML, BAML, .g.cs Details

Adam Kinney has posted his xaml app that he entered into a markup-bakeoff that Gerald Bauer organized.  Nice job Adam.

Follow Adam's link to all the entries - they are very interesting to read through.

Visual Appearance

I found it interesting that the different entries all had different looks based on the UI plaform they were built on top of.  This contest, I believe, has focused on the markup, not the appearance in the end.  In the end, a key differentiation will the be user experience.  In the end, Longhorn applications are going to be able to look significantly more polished than most other platforms.  The theme for our Buttons will evolve to take advantage of our vector rendering over time.

I was disappointed by the default look in Flex - I thought the buttons would have used more Flash power.
SwiXml targetting mac has the most polished controls right now.

Adam's entry shows off a few things that the others didn't have or didn't use:

• Flowing Layout - as you resize the window, the ui can reflow a bit.
• Non-gray look - gradients are a nice addition

With the just released WinHec build, Adam could consider using the new <Grid> to get different resizing characteristics than the FlowPanel.  (SimpleText gets replaced by Text in the winhec build also...)

Developer Experience

I like the fact that Adam used a style to set properties on all the Buttons

He should consider declaring the Gradient as a resource and use a resource reference on the FlowPanel's Background property.  This will keep the UI defintion cleaner.  It also shows off resource references.  I guess you want to keep it simple, but also want to show off some of the power...

Gerald - It would be interesting for the sample site to show the code behind for all the examples.  We are only seeing part of the picture for many of these samples.

Nigel McFarlane wrote a DevX piece “A Standards Based Look at XAML's Features”.

I'd like to make a few informational points for readers of that article and then have a place where people can add comments/questions.  The whole topic may warrant a long post, but I don't have time right now.

1. HTML + CSS modeled most elements as setting a few CSS attributes by default

Most text formatting tags could be thought of providing a different set of default values for those css-attributes.

This:

<bold>this is also bold</bold>

Is equivalent to:

<span style=”font-weight:bold”>this is bold</span>

Avalon's approach (which people can choose to use declaratively in XAML or via their favorite programming language) is very similar.

This:

<Bold>this is also bold</Bold>

Is equivalent to:

<Inline FontWeight=“bold“>this is bold</Inline>

2. HTML + CSS allow you to define stylesheets to avoid having to set all values directly on a tag

HTML + CSS allow you to do roughly this:
<html>
<head>
<style>
button { color : green }
</style>
</head>
<body>
    <button>my text that will be green</button>
</body>
</html>

Avalon allows you to similar things:
<TextPanel>
    <TextPanel.Resources>
        <Style>
             <Button Foreground=”green” />
        </Style>
    </TextPanel.Resources>
    <Button>This text will be green also</Button>
</TextPanel>

3. HTML + CSS allow you to use inheritance of values in the tree hierarchy.

In HTML, one could set many CSS properties in a ancestor element, and elements further down the tree would get that value.  Avalon supports component authors defining some properties as inheritable and support the same thing.

4. Avalon's Styles & Property System is different than CSS

CSS has its own language syntax.
Avalon's Styling system is XML based.

Avalon's Styling system isn't feature for feature equivalent to CSS.
In some cases, it is innovating in new spaces.  In a few cases, it can't match CSS for some scenarios.

We're listening to customers who are building real apps & solutions to see how we need to evolve our styling strategy before we ship.

Feel free to comment on what I wrote in this post or on any questions/comments you have from Nigel's article.

I was happy to read Chris Sells' MSDN article "Another Step Down the Longhorn Road".  Chris is building solitaire using Avalon. (This article was step 2 of 3).

This article goes into 2 of the 5 element families: Panels and Controls.  It also covers the details (and current gotchas) of how to build an application with a custom component.

One problem he points out:

"The problem is that the XAML gets the type information from a compiled assembly, so you'll have to add a reference to the custom control project in the containing project."

We have been wanting to fix this issue for a long time, we hope to have this fixed soon (in time for what I expect will be our 3rd public release of LH)  We'll make it possible to put PileOfCards.xaml & PileOfCards.xaml.cs into the applications project.

I'm looking forward to the final installment.

Chris positions XAML vs general serialization technologies and approaches.

...
XAML was designed to be a compromise markup format, that balanced the toolability and readability aspects of a markup. You can think of HTML as a markup that was squarely designed to be readable, but not very toolable. SOAP on the other hand is very toolable, but almost impossible to read. In the design of XAML we constantly walk the line between the two. XAML has support for inline code, customer parser extensions, and multiple representations of the same structure.
...

This piece hightlights some of the conflicting goals that influence the decisions we make with XAML.  It'll be a while before our current evolved design (what I'm calling xaml2004) makes it out to the world in a build, but I think people will be happy with the continued focus we have on moving XAML in a generic technology direction.

Readability and writability, I believe, is critical to the success of XAML.  Many folks will be using a visual designer, so they won't appreciate it, but I think many people will like to read/write it directly (at least occassionally).

Perhaps we are focusing on that too much now since we are all still using an XML editor to create XAML pages.  Once designers get built and have more use, we'll see if we'll change some of our decisions.  For now, I think it is important to walk that thin line...

Pablo Fernicola (Group Program Manager), David Ornstein (Lead Program Manager), Nathan Dunlap (Rockin' Designer), and I spent time yesterday with Robert Hess and the .Net Show crew.

The .Net Show blog posted about the filming (with links to photos) etc...

Interesting format.  Nathan showed the Login Screen demo a new demo showing using Paths for States and having those states in a ListBox.  I showed some basic xaml concepts, talked about markup and programming model and showed a bit of my Viewer application.

Once it goes live, you'll have to post feedback...I'm new to the whole video thing.

Thanks to Robert and crew for asking me to appear!