fortes.com

I’m finalizing my PDC travel arrangements. I’ll be in LA from Sunday afternoon to Friday morning. I’ll be staying at the Sheraton Universal, which is unfortunately over 10 miles away from the convention center. Apparently there will be shuttle service between the hotel and the conference though.

I spent time today getting familiar with the hands-on labs I’ll be helping out with; we have some simple copy-paste walkthroughs for people to go through and construct a demo app. The talks are good for high-level overviews, but the labs will likely be the first development experience (albeit limited) developers have with Longhorn. I’m excited to hear their feedback.

Editor’s note: This entry ported from a previous site. The original post may still be availalbe.

I guess I forgot to mention this: I’ve had serious hard drive problems during the past three days; some sectors of my hard drive have been overrun by thugs and ruffians. There are plenty of worse times this could have happened (during the PDC), but this is a headache I didn’t need. After attempting some diagnostics (the hard drive issues are serious enough to crash and/or hang the diagnostic tools I tried), I’ve now re-partitioned my hard drive, leaving 5 GBs of un-partitioned no-man’s land in the middle of my drive.

This means I should have a working laptop for the PDC, which I consider essential. There will be a ridiculous number of bloggers at the PDC, and I’m really looking forward to reading some real-time feedback.

Soon I’ll be able to write more than “I’m looking forward to the PDC.”

Editor’s note: This entry ported from a previous site. The original post may still be available.

After much difficulty, I’m finally in LA; it’s great to see all the excitement at the convention center.

I managed to miss all the interesting keynotes, and arrived at about 7pm in time to visit the exposition center and talk to a few people at the Avalon booth.

So what do I do in Avalon? Up until very recently (more about this later), I was the Program Manager for Avalon’s Layout API. I was working on everything from the Layout system and the functions which drive layout, to the layouts which developers will use to display everything from a dialog box to a 100 page document.

My role will be shifting in the future to concentrate more on Longhorn’s document story (of course, I’ll still have a role in the rest of Avalon’s layout API).

Editor’s note: This entry ported from a previous site. The original post may still be available.

I’m staying at the Sheraton Universal hotel, which is over 10 miles away from the PDC. Shuttle service to and from the convention center is provided, but LA traffic means the commute takes a while. This is, however, a convenient time to try to go through some RSS feeds and write some replies. (This is why I vastly prefer full-text RSS feeds)

Editor’s note: This entry ported from a previous site. The original post may still be available.

“What’s the difference between XAML and XUL?”

Comparisons to XUL have been frequent lately, so I’ll address the issue from my (layout-centric) point of view.

As Roger points out: XAML’s (and Avalon’s) scope is significantly larger than XUL’s; XUL was created for constructing Mozilla’s GUI, as well as the GUI for applications / services which leverage the Mozilla platform. Avalon is much larger than this. The amount of services and functionality we’re providing in Avalon is quite large, and will take a while to digest; but once people start to get it, it’ll be clear why XAML is much larger than XUL.

[Aside: it is difficult to separate XAML and Avalon. XAML is a way to use the Avalon APIs through markup, XAML is translated directly into managed code, calling the same APIs used when constructing an application through code.]

• XAML is far more extensible, you can use custom widgets and layouts from markup in XAML; doing so in XUL would require hacking into Mozilla’s source.
• Avalon plugs into the .NET framework’s numerous libraries; XUL provides JavaScript hooks into the DOM and Mozilla’s libraries, which although useful, aren’t as complete (or extensible) as .NET’s.
• Avalon provides a far richer model for documents than XUL. I will cover more of this in detail in future entries.
• Avalon provides a wide-variety of Application and Document services, including deployment, rich databinding, accessibility and automation, online / offline storage and persisitance, and editing services, to name a few. I’m aware that XUL / Mozilla provide some of these services [deployment (through XPI), some level of databinding, and probably others], but I believe Avalon’s services are much richer and more extensible. However, I’m not an expert in Avalon and Mozilla’s capabilities in these areas.
• XUL can’t be compiled, so you’ll always pay the performance cost of parsing.

There are many other differences — but my bus ride is over now. I’m certain this isn’t the last time I’ll be addressing these issues.

[Disclaimer: I’ve poked around with XUL before, but not very thoroughly — I may have some details wrong here. Feel free to correct me. I’ve used Dave Hyatt’s XUL summary as a refresher.]

Editor’s note: This entry ported from a previous site. The original post may still be available.

I’m proctoring the Hands on Labs, but my advice to attendees is to skip the labs.

Why? You’ve only got a limited amount of time at the PDC, so going to the labs means you’re missing out on a session, keynote, birds of a feather session, or socializing with fellow attendees, whereas the lab materials will be available online. You won’t have an Avalon team member over your shoulder, but you can easily ask questions through newsgroups or weblogs.

Editor’s note: This entry ported from a previous site. The original post may still be available.

Barry Gervin writes:

Another cool thing about longhorn is that the UI is all vector based. So you can do things like rotate your buttons and text boxes etc. Pretty cool, not very useful. Being able to zoom in on a part of your text though and still have a pretty (not aliased) image is wonderful.

Vector graphics do look quite good (and often take up less disk space than pixel-based graphics), but they’re definitely useful for other reasons.

If you’re at the PDC, stop by the Avalon booth and check out the 200 dpi monitor we have on display. Have the person working the booth fire up a few applications for you; notice how the bitmapped graphics are either:

1. (more likely) Tiny. It turns out that 100 pixels aren’t that large on a 200dpi monitor.
2. (less likely) Jaggy. Bitmaps don’t scale well.

With vectors you don’t have this problem. Scaling doesn’t only happen for high DPI monitors. Vision-impaired users need to be able to scale UI as well.

Also, using vectors from markup enables programmatic access to your graphics. With vector graphics in Avalon, changing the fill or stroke for a rectangle is trivial. Try doing that with a bitmap.

Editor’s note: This entry ported from a previous site. The original post may still be available.

I’m back in from the PDC, and more than a bit behind on my mail, reading, and weblog; patience.

Editor’s note: This entry ported from a previous site. The original post may still be available.