Эх, все таки Silverlight проигрывает WPF-у по удобству использования, столько ограничений, местами весьма бессмысленных. Когда же они доведут его до более менее близкого по эффективности к WPF-у продукта.

Да, мы сделали это - Fluent дорос до версии 1.3.

Теперь ещё лучше, ещё быстрее и ещё надёжнее. Есть версии как под .NET 3.5 так и под .Net 4.0

Все таки у майкрософтов TFS, несмотря на все свои достоинства, достаточно неудобен, если для работы с ним используются инструменты, отличные от Visual Studio (ну и Expression Blend-а, который к 3-ей версии с горем пополам научился работать с этим самым TFS-ом). Тот факт, что для начала редактирования файла его сначала надо захватить на сервере, в корне убивает все прелести работы с ним. Особенно, когда сервер удалённый а интернет работает кое-как. Бывает файл минут по 10 захватывается. И главное пользы от этого ноль, ибо кому какое дело, кто ещё редактирует этот файл, кроме тебя. Все таки, когда просто берёшь и правишь файл, без всяких заморочек - гораздо более удобный вариант (как сделано в SVN-е или там в Mercurial-е,), ибо позволяет пользоваться любыми инструментами, без всякой мороки типа - открыл Visual Studio, захватил файл, открыл Blend, поправил файл и т.д. Просто берёшь и правишь, и никаких проблем.

Странно как-то, в эмуляторе Windows Phone TouchLocation выдаёт координаты с каким-то сдвигом, причём этот сдвиг есть в его приватных полях, но без рефлекшена его никак не получить. Надо будет проверить - это глюк хакнутой версии эмулятора или и в нормальной тоже так.

В Windows Phone 7 и Zune HD API для работы с акселометром сделано абсолютно по разному. Поэтому когда надо отдебажить что-то использующее акселометр на Zune (ибо заполучить рабочий прототип Windows Phone нереально) приходится писать корявые обёртки. Крайне не одобряю, к тому же акселометровое API для Zune в разы удобнее для XNA-игр.

Почему-то большинство людей, которым доводилось делать ControlTemplate-ы для ContentControl-ов никогда не используют возможность ограничить тип этого самого контента. Например если у нас есть кнопка, про которую мы точно знаем, что там будет только картинка, то почему не задать её шаблон следующим образом:
И тогда в xaml-е можно ее будет задавать следующим образом:
Вместо традиционного:
Получается короче и удобнее в использовании. Естественно, использование данной возможности накладывает ограничение на использование таких шаблонов в незапланированных целях, поэтому допустим применять такую возможность в библиотеках компонентов будет не лучшей идей, но для использования внутри конкретного законченного проекта будет вполне удачно для упрощения и уменьшения написанного xaml-а.

Сегодня мы выпустили первый релиз Fluent-а

Оно уже вполне жизнеспособно, есть ещё кой-какие баги, но они по большей части связаны с контекстными меню и quick access toolbar-ом, которым почти никто не пользуется.
В общем несмотря на некоторые недостатки это лучше чем все бесплатные аналоги, а местами и лучше чем платные (что, впрочем, не удивительно, учитывая крайне невысокое качество последних), так что как пофиксим все мелочи да доработаем темы, то обойдём и платных :)
В общем всячески рекомендую - самые правильные риббоны для WPF-а

PS. Остальные скриншоты здесь.

Заметил, что если поставить у биндинга свойство IsAsync в true, то он не будет тормозить при загрузке, если в во ViewModel-и коллекция создана как-то так:
Т.е. он загрузит коллекцию асинхронно, соответственно если ещё поставить триггер на null, то можно рисовать красивую анимацию загрузки, что весьма удобно при больших объёмах данных.

Скачал релиз кандидат 2010-ой студии. В целом он радует - большинство тормозов бывших в бете они поправили, а уж после перекраски в серый цвет (уж больно эта студия синюшная по умолчанию) пользоваться им стало совсем приятно. Resharper и AnchSVN без всяких проблем подцепились. Я доволен. Из минусов - сломалась превью версия 4-го Expression Blend-а, видать с релиз кандидатом 4-го дотнета она работать не желает: обидно.

В общем и целом WPF мне нравится. Вещь замечательная, удобная и не имеющая аналогов. Из более менее близких можно назвать пожалуй Qt, благо после покупки Нокией он стал развиваться гораздо активней и в целом движется в относительно верном направлении. Ещё конечно можно назвать Htmlayout, но он все таки слегка из другой оперы, хоть на данный момент и является единственной возможностью создавать красивые нативные приложения под Windows (Qt я нативным не считаю, ибо это монстр ещё похлеще .Net). Так вот, WPF мне нравится, но иногда там встречаются настолько нетрадиционные решения, что волосы дыбом встают. Вот например есть скроллбар (ScrollBar) и мы хотим задать Thumb-у этого скроллбара некую минимальную высоту (или ширину в зависимости от того вертикальный ли это скроллбар или горизонтальный). Казалось бы что проще, ставишь MinHeight Thumb-а в нужное значение и наслаждаешься полученным результатом. А вот нет. Основной поведенческой логикой скроллбара заведует некий Track, который нисколько не волнуют всякие там MinHeight-ы и который тупо урезает Thumb до того размера, до которого сочтёт необходимым. После долгого ознакомления с MSDN-ом, выяснилось следующее: для минимального размера Thumb-а Track использует константу SystemParameters.VerticalScrollBarButtonHeightKey (точнее половину от значения этой константы), которая по умолчанию связана с дефолтным значением в Windows. И эту константу можно поменять в ресурсах Track-а примерно таким образом:
Век живи, век учись, так руки бы и оторвал тем индусам, которые такое наворотили.
К слову не могу не заметить, что ни в одном из видимых мною платных WPF-ных контролов, в котором был кастомный стиль на скроллбар, не было задано нужной минимальной высоты, поэтому во всех них наблюдались некоторые баги при достижении минимального значения. И это определённо свидетельствует о недостаточном качестве этих самых контролов. Вот посмотришь на чужие контролы и так и хочется заняться создание правильных контролов для WPF-а (и silverlight-а тоже), а то продаваемые сторонними конторами контролы в большинстве своём абсолютно никакие.