На недавно прошедшей онлайн конференции dotNetConf организованной Microsoft, рассказывалось множество интересных вещей. И коль скоро было большое количество обсуждений по поводу WPF, что он живее всех живых, то хочется сделать краткий обзор доклада программных менеджеров WPF, что нового нас ждет в релизе, что уже можно посмотреть и к чему все идет. Действительно все так плохо и будет ли аналог нового движка для WPF, как например Razor для ASP.NET.
12 ноября 2014 года блог WPF ожил (сейчас активен тоже) и был представлен генеральный план развития фреймворка.
Здесь и далее, скриншоты с видео, так что качество не очень, но разглядеть все можно.
В начале выступления, ведущие Уни Равиндранатан (Unni Ravindranathan) и Харикришна Менон (Harikrishna Menon) обмолвились, что есть вещи, которые еще находятся в разработке, и они не имеют права о них рассказывать, NDA и все такое. Но то что они могут показать, внушает оптимизм и видно, что работа идет. Забегая вперед, скажу, что прежде всего разработчики подумали о быстродействии, например, как сократить визуальное дерево для конкретной целевой платформы.
Ключевые области разработки показаны на скриншоте ниже:
Разработчики уверяют, что WPF никуда не денется и вопреки бытующих слухам, что WPF выпиливается из операционной системы – это не правда. DotNet часть ОС, и WPF часть ОС и ему будет уделяться не меньшее количество внимания, чем другим составляющим. В Microsoft уверены в том, что приложения для ОС будут еще долго писаться на WPF.
На портале Connect были пересмотрены и переоткрыты все баги, которые имели больше 10 голосов. И сейчас все еще есть возможность повлиять на то, какие фичи\баги будут разрабатываться.
В ближайшем релизе WPF будут решены проблемы, касающиеся вопросов:
Как было раньше туго с прозрачностью. Обходные пути видимо были, но сложные.
Для использования прозрачных дочерних окон вам требуется Windows 8 и выше, а также .NET 4.5.2.
Ну и еще одна деталь, в app.manifest надо указать что эта фича поддерживается ОС. Т.е. в разделе application написать следующее:
<application>
<!-- Windows 8-->
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
</application>
Другим популярным вопросом является что делать с курсорами при увеличении масштаба на экране. Курсор становится тоже большим. Приходилось вручную определять, что увеличился масштаб и перегружать курсоры на нужный размер. Чтобы все было красиво и аккуратно. Теперь можно указать в конструкторе курсора, что делать, если меняется масштаб отображения.
Еще одним адом перфекциониста было то, что для выпадающего списка правая граница была обрезана, и он выглядел от этого куце при изменении масштаба. В новой версии это исправили.
Вообще эта проблема присутствует для всех компонентов при увеличенном масштабе отображения. Причина заключается в неправильном отображении фона для компонентов.
Описанные проблемы относятся к существующему коду, однако всех больше интересует, что же будет дальше, какие новые штуки ждать от WPF.
Команда WPF хочет уменьшить цикл доставки обновлений и сократить насколько это возможно. Чтобы обновления выходили не раз в полгода, когда возможно вам уже ничего этого не надо, а по мере реализации запросов и найденных багов.
Кроме этого очень много внимания уделяется обратной совместимости. Так как WPF системная вещь, то поддержка DX12 или построение части компонентов на основе DX12 может повлиять на некоторое количество уже выпущенных программ. Мы не можем кинуть их на произвол судьбы и обязаны найти какое-то решение, для обеспечения обратной совместимости. Это конечно большая проблема. Если касаться вопросов быстродействия, то изменения должны почувствовать максимальное количество пользователей.
Абсолютно новая вещь, которая до момента конференции не упоминалась нигде – это AppLocal. Наверно это самое большое изменение сейчас. Оно заключается в том, что WPF как платформа может быть доставлена с помощью пакета NuGet нужной версии. Т.е. каждая версия приложения поставляется со своей уникальной версией WPF. Разработчики гарантируют, что вы получите лучшее или такое же быстродействие по сравнению со встроенной версией. Чаще все же будет улучшение производительности.
Такая версия WPF будет совместима со встроенной, но в то же время, можно построить версии WPF поверх NetCore.
В качестве демонстрации работы новой версии WPF приводится демо с таким вот оформлением.
Для начала приложение загружается со сборками 4.5.2. Видно, что ссылки идут на старую версию при разработке и будет обращение к GAC в runtime.
Теперь будет происходить магия. В выпадающем меню для сборок, выбирается пункт «Добавить NuGet пакетов» и можно установить желаемую локальную сборку WPF. К сожалению, это пока что доступно только для разработчиков WPF, на скриншоте ниже видно, что используется локальный репозиторий.
Во время установки заменяются ссылки с GAC сборок на локальные и в списке Referencies появляется достаточно много новых сборок, которые нужны именно вашему приложению для определенной платформы.
Так как это еще не готовое решение, то надо сделать немного шаманства с конфигурационными файлами и тогда все заработает.
После этого можно сделать сравнение с версией 4.5.2, на сколько сильно/слабо будет сокращено дерево элементов для графической интерфейса приложения. Итак, для достаточно простого интерфейса на версии .net 4.5.2 был создан 281 элемент.
После применения NuGet пакета с локальной версией WPF получилось 230.
Разработчики обещают отложенную инициализацию компонентов, так что они будут инициализированы только когда попадут в активную пользовательскую зону. Обещают, что подключать это можно будет одним движением, т.е. атрибутом.
Далее обзор Blend и снятия метрик быстродействия, которые уже отдельно освящались во многих местах, как мне кажется.
Вообще ведущие очень напирали на то, чтобы сообщество присылало им побольше всяких интересных кейсов использования WPF и в каких местах случаются затыки и проблемы. Так что пишите им письма =)
В этом контексте становится еще интереснее узнать, что же будет с WPF и Universal Application. Стоит ли мигрировать, сложно ли это и вообще в каких случаях стоит мигрировать, а в каких нет. Конечно, основные навыки по работе с WPF остаются востребованы и актуальны для Universal App, но отчего тогда столько шума? На эти вопросы ответит Костя Кичинский, эксперт по технологиям разработки программного обеспечения, Microsoft, на конференции Desktop UI & Business Application, которая состоится 11 апреля.
Доклад освящает основные вопросы касающиеся Universal App и WPF:
Приходите, будет интересно!
12 ноября 2014 года блог WPF ожил (сейчас активен тоже) и был представлен генеральный план развития фреймворка.
Здесь и далее, скриншоты с видео, так что качество не очень, но разглядеть все можно.
В начале выступления, ведущие Уни Равиндранатан (Unni Ravindranathan) и Харикришна Менон (Harikrishna Menon) обмолвились, что есть вещи, которые еще находятся в разработке, и они не имеют права о них рассказывать, NDA и все такое. Но то что они могут показать, внушает оптимизм и видно, что работа идет. Забегая вперед, скажу, что прежде всего разработчики подумали о быстродействии, например, как сократить визуальное дерево для конкретной целевой платформы.
Ключевые области разработки показаны на скриншоте ниже:
- Производительность, быстродействие при скроллинге, виртуализации данных. Поддержка экранов с высокой плотностью пикселей. Многие справедливо критикуют WPF за скорость работы, особенно при скроллинге.
- Поддержка для DX11 и DX12
- Поддержка современного оборудования. Отзывчивость и реакция на тач-события.
- Инструментарий для разработки и дебага приложений.
Разработчики уверяют, что WPF никуда не денется и вопреки бытующих слухам, что WPF выпиливается из операционной системы – это не правда. DotNet часть ОС, и WPF часть ОС и ему будет уделяться не меньшее количество внимания, чем другим составляющим. В Microsoft уверены в том, что приложения для ОС будут еще долго писаться на WPF.
Ближайшие планы по улучшению WPF
На портале Connect были пересмотрены и переоткрыты все баги, которые имели больше 10 голосов. И сейчас все еще есть возможность повлиять на то, какие фичи\баги будут разрабатываться.
В ближайшем релизе WPF будут решены проблемы, касающиеся вопросов:
- производительности и тач-девайсов
- скроллинг и виртуализация
- так же сделали возможность создавать прозрачные дочерние окна.
Как было раньше туго с прозрачностью. Обходные пути видимо были, но сложные.
Для использования прозрачных дочерних окон вам требуется Windows 8 и выше, а также .NET 4.5.2.
Ну и еще одна деталь, в app.manifest надо указать что эта фича поддерживается ОС. Т.е. в разделе application написать следующее:
<application>
<!-- Windows 8-->
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
</application>
Другим популярным вопросом является что делать с курсорами при увеличении масштаба на экране. Курсор становится тоже большим. Приходилось вручную определять, что увеличился масштаб и перегружать курсоры на нужный размер. Чтобы все было красиво и аккуратно. Теперь можно указать в конструкторе курсора, что делать, если меняется масштаб отображения.
Еще одним адом перфекциониста было то, что для выпадающего списка правая граница была обрезана, и он выглядел от этого куце при изменении масштаба. В новой версии это исправили.
Вообще эта проблема присутствует для всех компонентов при увеличенном масштабе отображения. Причина заключается в неправильном отображении фона для компонентов.
Описанные проблемы относятся к существующему коду, однако всех больше интересует, что же будет дальше, какие новые штуки ждать от WPF.
Команда WPF хочет уменьшить цикл доставки обновлений и сократить насколько это возможно. Чтобы обновления выходили не раз в полгода, когда возможно вам уже ничего этого не надо, а по мере реализации запросов и найденных багов.
Кроме этого очень много внимания уделяется обратной совместимости. Так как WPF системная вещь, то поддержка DX12 или построение части компонентов на основе DX12 может повлиять на некоторое количество уже выпущенных программ. Мы не можем кинуть их на произвол судьбы и обязаны найти какое-то решение, для обеспечения обратной совместимости. Это конечно большая проблема. Если касаться вопросов быстродействия, то изменения должны почувствовать максимальное количество пользователей.
AppLocal
Абсолютно новая вещь, которая до момента конференции не упоминалась нигде – это AppLocal. Наверно это самое большое изменение сейчас. Оно заключается в том, что WPF как платформа может быть доставлена с помощью пакета NuGet нужной версии. Т.е. каждая версия приложения поставляется со своей уникальной версией WPF. Разработчики гарантируют, что вы получите лучшее или такое же быстродействие по сравнению со встроенной версией. Чаще все же будет улучшение производительности.
Такая версия WPF будет совместима со встроенной, но в то же время, можно построить версии WPF поверх NetCore.
В качестве демонстрации работы новой версии WPF приводится демо с таким вот оформлением.
Для начала приложение загружается со сборками 4.5.2. Видно, что ссылки идут на старую версию при разработке и будет обращение к GAC в runtime.
Теперь будет происходить магия. В выпадающем меню для сборок, выбирается пункт «Добавить NuGet пакетов» и можно установить желаемую локальную сборку WPF. К сожалению, это пока что доступно только для разработчиков WPF, на скриншоте ниже видно, что используется локальный репозиторий.
Во время установки заменяются ссылки с GAC сборок на локальные и в списке Referencies появляется достаточно много новых сборок, которые нужны именно вашему приложению для определенной платформы.
Так как это еще не готовое решение, то надо сделать немного шаманства с конфигурационными файлами и тогда все заработает.
После этого можно сделать сравнение с версией 4.5.2, на сколько сильно/слабо будет сокращено дерево элементов для графической интерфейса приложения. Итак, для достаточно простого интерфейса на версии .net 4.5.2 был создан 281 элемент.
После применения NuGet пакета с локальной версией WPF получилось 230.
Улучшение быстродействия
Разработчики обещают отложенную инициализацию компонентов, так что они будут инициализированы только когда попадут в активную пользовательскую зону. Обещают, что подключать это можно будет одним движением, т.е. атрибутом.
Далее обзор Blend и снятия метрик быстродействия, которые уже отдельно освящались во многих местах, как мне кажется.
Вообще ведущие очень напирали на то, чтобы сообщество присылало им побольше всяких интересных кейсов использования WPF и в каких местах случаются затыки и проблемы. Так что пишите им письма =)
В этом контексте становится еще интереснее узнать, что же будет с WPF и Universal Application. Стоит ли мигрировать, сложно ли это и вообще в каких случаях стоит мигрировать, а в каких нет. Конечно, основные навыки по работе с WPF остаются востребованы и актуальны для Universal App, но отчего тогда столько шума? На эти вопросы ответит Костя Кичинский, эксперт по технологиям разработки программного обеспечения, Microsoft, на конференции Desktop UI & Business Application, которая состоится 11 апреля.Доклад освящает основные вопросы касающиеся Universal App и WPF:
- Развитие WPF и появление WinRT
- Унификация Windows-платформы и UAP
- Инвестиции в WPF
- Как WPF стыкуется с UAP + матрица миграции (когда и как стоит мигрировать, а когда нет)
Приходите, будет интересно!
