На недавно прошедшей онлайн конференции 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 + матрица миграции (когда и как стоит мигрировать, а когда нет)
Приходите, будет интересно!
Комментарии (12)
Ogoun
08.04.2015 18:02+4А про доработку XAML ничего нет? Чтобы не писать каждый раз bool — visible конвертеры, например. Еще сильно мешает что шаг влево, шаг вправо и вьювер в XAML редакторе падает, при этом все билдится и запускается.
VioletTape Автор
08.04.2015 18:06Было много про Blend, но чего-то особенного про сам XAML не рассказывали, насколько помню.
Да, такие вылеты редактора тоже раздражают, но никаких подвижек пока не сообщают. Но об этом можно написать программным менеджерам ;)
PsyHaSTe
08.04.2015 18:41+9Блин, вот ну не верю я в это. Что нужно сделать:
1) переработать нечитаемый XAML
2) отрефакторить весь фреймворк (функция с 20 ref-параметрами это же АД)
3) вместо тучи internal abstract классов сделать публичные интерфейсы
4) следствие третьего, добавить точки расширения
5) добавить нормальную отрисовку — 3! команды отрисовки на каждый контрол в окне, которых начитываются сотни, это же такая жесть…
6) Поддержка dependency props на уровне самого WPF, а не путем разбора атрибутов всякими postsharp.
7) Привести ICommand в человеческий вид.
8)… Да хотя бы эти 7 пунктов — я бы в тот же момент с радостью вернулся на WPF… А пока что — это путь боли и страданий…
Поймите правильно, я только ЗА настольную разработку на шарпе, но глядя на проблемы WPF возникает впечатление, что проще разработать аналог с нуля, учитывая опыт WPF и изменения в архитектуре и подходах за 10 последний 10 лет, чем внести в фреймворк столько изменений…
Nagg
08.04.2015 18:59+5XAML порой ужасен, я бы вообще взял за основу QML, а то полотно XML иногда вообще не читаемо. Описывать стили — это вообще геморой. Как сделать стиль для тесктового поля, который описал бы размер шрифта и градиентную закраску? нет ничего проще:
<Style BasedOn="{StaticResource {x:Type TextBlock}}" TargetType="TextBlock" x:Key="TitleText"> <Setter Property="FontSize" Value="26"/> <Setter Property="Foreground"> <Setter.Value> <LinearGradientBrush StartPoint="0.5,0" EndPoint="0.5,1"> <LinearGradientBrush.GradientStops> <GradientStop Offset="0.0" Color="#90DDDD" /> <GradientStop Offset="1.0" Color="#5BFFFF" /> </LinearGradientBrush.GradientStops> </LinearGradientBrush> </Setter.Value> </Setter> </Style>
А так, да, главное:
1) Перфоманс (скорость запуска и рендеринг сложных форм)
2) Шрифты — вырвиглазное мыло (с обычным, офисным DPI).
3) Унификация с windows 8, wp8
4) И, желательно, всё в опен сорс.
DreamWalker
08.04.2015 20:19+4Согласен с вами. С одной стороны, я понимаю почему XAML такой: некоторые его подходы обеспечивают высокий уровень гибкости. Плюс, абсолютно понятно как XAML отображается в стандартные классы. WPF позволяет делать удивительные вещи. Но вот сам XAML далеко не всегда радует, это правда. Лично меня больше всего всегда гриды печалили. Очень хочется, чтобы вместо
<Grid> <Grid.RowDefinitions> <RowDefinition Height="Auto" /> <RowDefinition Height="Auto" /> <RowDefinition Height="*" /> <RowDefinition Height="28" /> </Grid.RowDefinitions> <Grid.ColumnDefinitions> <ColumnDefinition Width="Auto" /> <ColumnDefinition Width="200" /> </Grid.ColumnDefinitions> </Grid>
можно было бы писать что-нибудь в духе
<Grid RowDefinitions="Auto,Auto,*,28" ColumnsDefinitions="Auto,200"> </Grid>
RinatMullayanov
С AppLocal можно будет запустить приложение на компьютере на котором вообще нет WPF (в том числе на Windows XP)?
VioletTape Автор
Из объяснений ведущих, я понял, что будет что-то очень близкое к этому. Потому как дальнейшая нацеленность на отчуждаемость WPF движка и возможность переноса на другие ОС.
Т.е. для поздних Windows такая опция может быть не столь актуальна, но для других ОС очень даже.
Более того, такой механизм распространения и использования WPF позволит сделать релизы более частыми, а значит оперативно реагировать на запросы больших бизнесов, и вводить новые фишки, не дожидаясь основных обновлений языка. Примерно как ASP.NET. При таком подходе не будут «ломаться» разные версии приложений, так как работают с фиксированной версией WPF. Отлично же!
RinatMullayanov
Звучит крайне здорово, а когда это фича выйдет в релиз хотя бы ориентировочно?
VioletTape Автор
Мне кажется что с выпуском новой студии это должно уйти в релиз. В видео показывали что это уже работает из локальной репки NuGet, так что в целом это должно быть политическое решение, когда отправить это в большой мир.
ad1Dima
Сомневаюсь. NuGet пакеты все ещё зависят от версии .NET.