Здравствуйте, IB, Вы писали:

G>>Да, их не много. Но среди тех, что использую я managed нет.
IB>Десятую студию тоже не пользуешь? =)

*Новые приложения*. Студия к таковым не относится. Кстати, вот для повышения образованности — назови хотя бы еще пару wpf приложений которыми ты пользуешься?

Здравствуйте, Gollum, Вы писали:

G>Здравствуйте, gandjustas, Вы писали:

G>>>Тогда почему не появилось большое количество десктопных приложений на WPF?
G>>А сколько вообще новых приложенй для десктопа появилось за последние 10 лет?

G>Да, их не много. Но среди тех, что использую я managed нет.

А вот у меня наоборот: Paint.net, Live Writer, Catalyst Control Panel, Visual Studio, Expression Blend. Остальное — офис, аська, скайп, все сильно старше 5 лет.

Здравствуйте, Gollum, Вы писали:

G>*Новые приложения*. Студия к таковым не относится. Кстати, вот для повышения образованности — назови хотя бы еще пару wpf приложений которыми ты пользуешься?

ILSpy, SharpDevelop

Здравствуйте, gandjustas, Вы писали:

G>А вот у меня наоборот: Paint.net, Live Writer, Catalyst Control Panel, Visual Studio, Expression Blend. Остальное — офис, аська, скайп, все сильно старше 5 лет.

Кстати, после того как эти умники из AMD переписали Каталиклизус на WPF им стало решительно неудобно пользоваться, особенно на мониторах с большим разрешением.

> Можно пример того, что очень плохо сделано в WPF? Из того, чем я пользовался — однозначно лучший UI Framework (для программиста).

Монструозный код, который если бы переписал хороший программист, сократился бы раза в два минимум даже без изменения подходов. Неправильные подходы, понятия, ненужные сущности, которые ни разу не упрощают разработку. Там где интерфейс может перерисовываться за 10-20 миллисекунд, он перерисовывается в режиме слайд-шоу. Приложение с одной кнопкой на рядовой машине может запускаться 15 секунд. и тд. Зачем об этом спрашивать?

> С верой не поспоришь.

Я не требую предъявить факты, хотя бы скажи свое честно слово, что вот такого:

"внутри у них так же конкурирующие рабочие группы"

у них нет? Нет рисковых перспективных разработок, они знают заранее что нужно делать (руководство уже приняло архитектурные решения) и на каждое направление у них есть фиксированная структура подразделений, постоянный штат, спущенное сверху "штатное расписание"?

Здравствуйте, hardcase, Вы писали:

G>>А вот у меня наоборот: Paint.net, Live Writer, Catalyst Control Panel, Visual Studio, Expression Blend. Остальное — офис, аська, скайп, все сильно старше 5 лет.
H>Кстати, после того как эти умники из AMD переписали Каталиклизус на WPF им стало решительно неудобно пользоваться, особенно на мониторах с большим разрешением.
А что не так на мониторах с большим разрешением? У меня нет карты AMD, поэтому сам посмотреть не могу

Здравствуйте, grosborn, Вы писали:

>> Можно пример того, что очень плохо сделано в WPF? Из того, чем я пользовался — однозначно лучший UI Framework (для программиста).
G>Монструозный код, который если бы переписал хороший программист, сократился бы раза в два минимум даже без изменения подходов. Неправильные подходы, понятия, ненужные сущности, которые ни разу не упрощают разработку. Там где интерфейс может перерисовываться за 10-20 миллисекунд, он перерисовывается в режиме слайд-шоу. Приложение с одной кнопкой на рядовой машине может запускаться 15 секунд. и тд. Зачем об этом спрашивать?
Не мог бы ты раскрыть выделенное? С монструозным кодом согласен, в кишки WPF порой страшно заглядывать.

Здравствуйте, MxMsk, Вы писали:

MM>А что не так на мониторах с большим разрешением? У меня нет карты AMD, поэтому сам посмотреть не могу

Дебильная нафигация по настройкам в виде дерева (впрочим она была и в прежнем каталисте), которое нужно самому раскрывать — мышкой нужно еще умудриться попасть в [+]. Крайне мелкие шрифты. Странная прокрутка простыней из ползунков настроек. Было — хреново (но зато со шкурками!!), стало — еще хуже. Нафига они переписали на WPF — не ясно... Технология-то сильно мощнее чем WinForms, позволяет значительно удобнее организовать интерфейс, в общем грустно.

Здравствуйте, MxMsk, Вы писали:

MM>А что не так на мониторах с большим разрешением? У меня нет карты AMD, поэтому сам посмотреть не могу

А ещё, куда-то пропали кнопки _ [ ] [x] в правом верхнем углу. В общем эти парни решили сэкономить на позиции юзабилити специалиста.

> Неправильные подходы, понятия, ненужные сущности, которые ни разу не упрощают разработку.
> Не мог бы ты раскрыть выделенное?

Если разрабатывать библиотеку исходя из анализа процессов написание гуи приложения, то получится совсем другой состав требований и другие архитектурные решения. Причем это достаточно однозначно. Например, идеология привязать событие мышки к конкретному визуальному примитиву. Это однозначно, что они "применяли технологию", нежели "автоматизировали работу". При "автоматизировали работу" привязка была бы к другой сущности. А затрудняя работу разработчика, мы тем самым косвенно снижаем функциональность и презентабельность интерфейса. Правильный же подход — "автоматизировали работу" должно иметь приоритет над "применяли технологию".
Это один пример из множества.

Здравствуйте, grosborn, Вы писали:

G>Монструозный код, который если бы переписал хороший программист, сократился бы раза в два минимум даже без изменения подходов. Неправильные подходы, понятия, ненужные сущности, которые ни разу не упрощают разработку. Там где интерфейс может перерисовываться за 10-20 миллисекунд, он перерисовывается в режиме слайд-шоу. Приложение с одной кнопкой на рядовой машине может запускаться 15 секунд. и тд. Зачем об этом спрашивать?

Вот я пока могу выделить из написанного две проблемы:
а) Претензии к удобству программирования.
Тут я не совсем соглашусь наверное, по крайней мере для меня неправильность подхода не столь очевидна. Но это можно замять, потому что вся неприятность в следующем пункте:

б)Слайд-шоу, 15 секунд на запуск приложения с одной кнопкой
Вот, собственно, это мне и не нравится, и я думаю что WinRT вполне способен эту проблему решить

Здравствуйте, grosborn, Вы писали:

G>Если разрабатывать библиотеку исходя из анализа процессов написание гуи приложения, то получится совсем другой состав требований и другие архитектурные решения. Причем это достаточно однозначно. Например, идеология привязать событие мышки к конкретному визуальному примитиву. Это однозначно, что они "применяли технологию", нежели "автоматизировали работу". При "автоматизировали работу" привязка была бы к другой сущности. А затрудняя работу разработчика, мы тем самым косвенно снижаем функциональность и презентабельность интерфейса. Правильный же подход — "автоматизировали работу" должно иметь приоритет над "применяли технологию".
Нельзя ли более предметно? Что нужно было сделать вместо того, что сделано сейчас?

Здравствуйте, Gollum, Вы писали:

G>Вот я пока могу выделить из написанного две проблемы:
G>а) Претензии к удобству программирования.
G>Тут я не совсем соглашусь наверное, по крайней мере для меня неправильность подхода не столь очевидна. Но это можно замять, потому что вся неприятность в следующем пункте:

XML для "языка создания объектов" (чем по сути и является XAML) — это фейл, впрочим чистого XML-я им нехватило — прикрутили {Binding ...} (да-да, закон дырявых абстракций в силе). Почему же они не сделали отдельный язык для этого (апеллирую к JSON и прочим YAML)?

Здравствуйте, hardcase, Вы писали:

H>XML для "языка создания объектов" (чем по сути и является XAML) — это фейл, впрочим чистого XML-я им нехватило — прикрутили {Binding ...} (да-да, закон дырявых абстракций в силе). Почему же они не сделали отдельный язык для этого (апеллирую к JSON и прочим YAML)?
Ой. Да никакой разницы. Ну двоеточие вместо равно, ну фигурные скобки, вместо вложенного тега. Не принципиально. И в чем кроется роль Binding-а, как решателя недостатков XAML?

Здравствуйте, MxMsk, Вы писали:

MM>Здравствуйте, hardcase, Вы писали:

H>>XML для "языка создания объектов" (чем по сути и является XAML) — это фейл, впрочим чистого XML-я им нехватило — прикрутили {Binding ...} (да-да, закон дырявых абстракций в силе). Почему же они не сделали отдельный язык для этого (апеллирую к JSON и прочим YAML)?
MM>Ой. Да никакой разницы. Ну двоеточие вместо равно, ну фигурные скобки, вместо вложенного тега. Не принципиально. И в чем кроется роль Binding-а, как решателя недостатков XAML?

XML многословен и неудобен для ручного написания. Сравни с конструкцией инициализации в C# (в Nemerle этой конструкцией можно вообще целые формы изготавливать). Без "расширений", лишь средствами XML, этот Binding выглядел бы предельно хреново.

Кстати, а как насчет простеньких выражений a + b и ValueConverter-ов на базе лямбд?

> Нельзя ли более предметно? Что нужно было сделать вместо того, что сделано сейчас?

Архитектурно? Там много чего должно быть сделано иначе. Как минимум понятие элемент проектирования не соответствует понятию визуальный элемент/примитив, опираясь на это образуется другая структура рабочих объектов. Но я не буду здесь писать вам архитектуру, поскольку это надо со специалистом разговаривать, а в этом форуме может только к холивару привести.

> Нельзя ли более предметно? Что нужно было сделать вместо того, что сделано сейчас?

Архитектурно? Там много чего должно быть сделано иначе. Как минимум понятие элемент проектирования не соответствует понятию визуальный элемент/примитив, опираясь на это образуется другая структура рабочих объектов. Но я не буду здесь писать вам архитектуру, поскольку это надо со специалистом разговаривать, а в этом форуме может только к холивару привести.

Здравствуйте, hardcase, Вы писали:

H>XML многословен и неудобен для ручного написания. Сравни с конструкцией инициализации в C# (в Nemerle этой конструкцией можно вообще целые формы изготавливать). Без "расширений", лишь средствами XML, этот Binding выглядел бы предельно хреново.
H>Кстати, а как насчет простеньких выражений a + b и ValueConverter-ов на базе лямбд?
Ах, вон о чем речь. Ну, может быть, может быть. Не берусь утверждать 100%, что это было бы реально удобнее. Врядли конструкции для Binding-а стали бы проще. Лямбды в конвертерах имеют и обратную сторону: код размазывается между декларативной и императивной частью.

Здравствуйте, MxMsk, Вы писали:

MM>Лямбды в конвертерах имеют и обратную сторону: код размазывается между декларативной и императивной частью.

Не знаю что ты понимаешь под императивом, но у меня хватает конвертеров, использующихся один раз и содержащих 1-2 строки вида

  simpleCondition(value) ? Visibility.Collapsed : Visibility.Visible;

либо

  ((FooType)value).PrettyPrint()

и т.п.

Нафига в этом случае 1) объявлять класс, 2) декларировать его в ресурсах, 3) ссылаться из байндинга.

PS Имею дело с Сервелатом.