Комментарии 12
С AppLocal можно будет запустить приложение на компьютере на котором вообще нет WPF (в том числе на Windows XP)?
Из объяснений ведущих, я понял, что будет что-то очень близкое к этому. Потому как дальнейшая нацеленность на отчуждаемость WPF движка и возможность переноса на другие ОС.
Т.е. для поздних Windows такая опция может быть не столь актуальна, но для других ОС очень даже.
Более того, такой механизм распространения и использования WPF позволит сделать релизы более частыми, а значит оперативно реагировать на запросы больших бизнесов, и вводить новые фишки, не дожидаясь основных обновлений языка. Примерно как ASP.NET. При таком подходе не будут «ломаться» разные версии приложений, так как работают с фиксированной версией WPF. Отлично же!
Т.е. для поздних Windows такая опция может быть не столь актуальна, но для других ОС очень даже.
Более того, такой механизм распространения и использования WPF позволит сделать релизы более частыми, а значит оперативно реагировать на запросы больших бизнесов, и вводить новые фишки, не дожидаясь основных обновлений языка. Примерно как ASP.NET. При таком подходе не будут «ломаться» разные версии приложений, так как работают с фиксированной версией WPF. Отлично же!
Сомневаюсь. NuGet пакеты все ещё зависят от версии .NET.
А про доработку XAML ничего нет? Чтобы не писать каждый раз bool — visible конвертеры, например. Еще сильно мешает что шаг влево, шаг вправо и вьювер в XAML редакторе падает, при этом все билдится и запускается.
Блин, вот ну не верю я в это. Что нужно сделать:
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 лет, чем внести в фреймворк столько изменений…
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 лет, чем внести в фреймворк столько изменений…
XAML порой ужасен, я бы вообще взял за основу QML, а то полотно XML иногда вообще не читаемо. Описывать стили — это вообще геморой. Как сделать стиль для тесктового поля, который описал бы размер шрифта и градиентную закраску? нет ничего проще:
А так, да, главное:
1) Перфоманс (скорость запуска и рендеринг сложных форм)
2) Шрифты — вырвиглазное мыло (с обычным, офисным DPI).
3) Унификация с windows 8, wp8
4) И, желательно, всё в опен сорс.
<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) И, желательно, всё в опен сорс.
Согласен с вами. С одной стороны, я понимаю почему 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>
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
WPF 4.6 и дальнейшие планы