Неплохо. Особенно мне понравился ваш вариант оформления режима предварительного просмотра в виде таба. Панель настройки видимости с то варианте, который у вас, весьма спорна, поскольку скрывает от пользователя значительную часть информации. Да и с расширением рабочего пространства нужно быть аккуратнее. Я полагаю что верстка будет резиновой и редактор «растянеться» когда пользователь распахнет панель «Настройка публикации»?
Ну тут как раз я решил не лукавить и не трогать панель редактора. Дело в том, что редактор — это встраиваемый элемент управления, который команда ЖЖ всего лишь задействовала в своем коде. И особо менять в нем они ничего не хотят, насколько я подозреваю. Поэтому здесь была проблема всего лишь в уехавшей панельке из-за недостатка ширины. А так да — я бы тоже поместил эти действия в начало :)
Знаете — я неоднократно им писал с предложениями по улучшению интерфейса и юзабилити. И получил ответ всего лишь один раз — после третьего письма. Ответ был шаблонным и содержал стандартную отмазку — что-то в духе «в настоящее время компания не располагает свободными ресурсами для решения подобных задач, так как все наше внимание обращено к повышению качества предоставляемых услуг». Читай между строк — все наше внимание обращено к тому, как бы заработать бабла на рекламе и прочем фуфлу побольше, а потратить на поддержку и разработку поменьше. Вообще судя по тому, что ничего не сдвигается с места уже несколько лет — СУП занимается лишь отбиванием денег из ЖЖ. На все остальное им начхать с высокой колокольни.
Только хотел сформулировать задание «Убить всех человеков», как наткнулся в правилах, что можно формулировать только задания, не противоречащие УК РФ :)
Маленькое дополнение — надо было сразу об этом сказать. Dispatcher, на мой взгляд, лучше ложится в схему приложения, использующего паттерн MVVM. Это сугубо из личного опыта — мне гораздо удобнее стало, когда я перешел на использование Dispatcher. Поскольку там вы свободно можете выполнять код в потоке UI Dispatcher. При использовании BackgroundWorker у вас такой возможности нет. Да и информацию о прогрессе вы можете передать только в рамках навазываемого коллбэка private void ProgressChanged(object sender, ProgressChangedEventArgs e), что накладывает определенные ограничения.
Подходит. Но это для того случая, если требуется выполнить некоторое действие в фоне. Здесь же основной акцент на Binding и то, что не приходится прилагать усилий — ядро WPF сделает все само. А с BackgroundWorker вам придется попыхтеть с реализацией правильной синхронизации. Да и работа с ним в рамках связывания данных не совсем простая — поверьте, приходилось сталкиваться.
Вообще для реализации операций с потоками в UI лучше использовать более новую концепцию — класс Dispatcher. Дизайнеры .NET Framework рекомендуют использовать этот класс вместо BackgroundWorker, который считается устаревшей концепцией .NET Framework 2.0.
Там еще помимо этого такая куча косяков в визуальной оформлении, что ахнешь. Я этот рибон уже задействовал в текущем проекте, который до этого был ни их же версии но CTP — которая еще с круглой кнопкой была а-ля Office 2007. Кода пришлось перелопатить… Правда я к этому готов был — они предупреждали что RibbonCommand будет удален. Зато количество кода уменьшилось за счет выкидывания костылей к этому самому ихнему RibbonCommand, поскольку проект использует паттерн MVVM.
А с кнопкой меню риббона (синяя, самая первая) пришлось играть с Margin чтобы она выглядела как системная и не вылезала выше остальных вкладок… Короче ложанулись разработчики с этим контролом.
А вы Fluent Ribbon много использовали в работе? Он позволяет сделать такой же Workspace как в Office 2010?
Возьмине майкрософтовский Whitepaper в котором описаны различия и смотрите не использовали ли вы что-то из запрещенных конструкций, классов и прочего — в общем всего того, чего нет в Silverlight. Например пространство имет System.Data и все что в нем полностью не совместимы — в Silverlight гораздо более урезанная версия. И так далее. Когда мы в нашем прокте насчитали сходу 429 ошибок — у нас это быстро отбило охоту продолжать :)
По сути Silverlight базируется на СОБСТВЕННОМ фреймворке. У него свой System.dll, System.Data.dll. Там СВОЯ система сборок, пересекающаяся с основной .NET Framework 3.51 ТОЛЬКО названиями типов. Т.е. там СВОЙ string, int и так далее. Мы пытались нахаляву проект в сильверлайт перевести как-то для эксперимента, налетели на это и очень удивились.
Хочу выразить признательность за хорошую стратью и уважение автору. Хотелось бы чтобы таких исков было побольше. Если бы все клиенты были такими как вы — может в этой нашей стране отношение к потребителям стало бы на порядок лучше.
Вообще для реализации операций с потоками в UI лучше использовать более новую концепцию — класс Dispatcher. Дизайнеры .NET Framework рекомендуют использовать этот класс вместо BackgroundWorker, который считается устаревшей концепцией .NET Framework 2.0.
А с кнопкой меню риббона (синяя, самая первая) пришлось играть с Margin чтобы она выглядела как системная и не вылезала выше остальных вкладок… Короче ложанулись разработчики с этим контролом.
А вы Fluent Ribbon много использовали в работе? Он позволяет сделать такой же Workspace как в Office 2010?
этойнашей стране отношение к потребителям стало бы на порядок лучше.