Здравствуйте, Михаил Романов, Вы писали:

МР>Ну я бы не стал утверждать, что прямо "похоронили" (в сравнении с реально заброшенным SilverLight, например, или Windows Phone, ...)
МР>Она в режиме поддержки: на Core мигрировали, особо мешающие баги правят, есть какой-то куций, конечно, и в основном ориентированный не на развитие, а на ту же поддержку Roadmap.

Все еще лучше. Её открыли в опенсорс и теперь её поддерживает не только МС по остаточному принципу, но и комьюнити. Мы, например, используем свой форк, а не исходную версию (причем даже не WPF, а всего дотнета и библиотек). В таком виде бояться прекращения поддержки вообще не стоит. Не МС, так комьюнити.

МР>Каких-то серьезных шагов развития нет, это не оспоришь, но, с другой стороны,

А что там развивать? Библиотека самодостаточна. Позволяет легко писать свои контролы и делать верстку. По сути её не особо нужно какое-то развитие. Того что есть хватает для любых извращений.

МР>если принять за базу тезис "десктоп схлопывается", то как-то ожидать серьезных вложений в чисто десктопную технологию было бы странно, имхо.

Я не знаю куда он там схлопывается. Сейчас мода на полувебнутые интерфейсы. Она пройдет как и всё остальное. Для телефонов один фиг принято писать нативные приложения просто потому, что они больше возможностей могут использовать и легче.

МР>Но для тех, кто в свое время сделал ставку на WPF/Windows — это всё равно, хороший момент: ты можешь продолжать и развивать и поддерживать свой продукт, не пытаясь судорожно переписать его на что-то иное.

+1

Особенно для разных государственных и окологосударственных контор, которые уже сделали гуй для Винды и сейчас их толкают к переносу этого всего на Линукс.

K>>Видимо, что-то не так, раз WPF сама Microsoft решила не поддерживать и предпочла купить Xamarin.
МР>Ну они ведь принципиально разные, на сколько я понимаю
МР>- WPF — чистый десктоп и использующий свой рендеринг
МР>- Xamarin.Forms/MAUI — это обертка для нативных библиотек и компонентов

В МС всё определяется борьбой отделов. Каждый должен сделать такой же продукт как у других но другой:

	История программных революций от Microsoft, вкратце
	Сначала были Windows API и DLL Hell. Революцией №1 было DDE – помните, как ссылки позволили нам создавать статусные строки, отражающие текущую цену акций Microsoft? Примерно тогда же Microsoft создала ресурс VERSION INFO, исключающий DLL Hell. Но другая группа в Microsoft нашла в DDE фатальный недостаток – его писали не они! Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием «по месту», при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, возникла MFC решившая все наши проблемы еще раз. Но OLE не собиралась, сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда – и даже включает тщательно разработанную систему версий компонентов, исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток – его писали не они! Они немедленно исправили этот недочет, создав ATL, который как MFC, но другой, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через броузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!). Группа операционных систем громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к Cairo, некой таинственной хреновине, которую никогда не могли даже толком описать, не то, что выпустить. К их чести, следует сказать, что они не представляли концепции «System File Protection», исключающей DLL Hell. Но тут некая группа в Microsoft нашла фатальный недостаток в Java — её писали не они! Это было исправлено созданием то ли J, то ли Jole, а может, и ActiveJ (если честно, я просто не помню), точно такого же как Java, но другого. Это было круто, но Sun засудило Microsoft по какому-то дряхлому закону. Это была явная попытка задушить право Microsoft выпускать такие же продукты, как у других, но другие. Помните менеджера по J/Jole/ActiveJ, стучащего по столу туфлей и говорящего, что Microsoft никогда не бросит этот продукт? Глупец! Все это означало только одно – недостаток внимания к группе ActiveX (или это был COM?). Эта невероятно жизнерадостная толпа вернулась с COM+ и MTS наперевес (может, это стоило назвать ActiveX+?). Непонятно почему к MTS не приставили «COM» или «Active» или «X» или «+» – они меня просто потрясли этим! Они также грозились добавить + ко всем модным тогда выражениям. Примерно тогда же кое-кто начал вопить про «Windows DNA» (почему не DINA) и «Windows Washboard», и вопил некоторое время, но все это почило раньше, чем все поняли, что это было. К этому моменту Microsoft уже несколько лет с нарастающей тревогой наблюдала за интернет. Недавно они пришли к пониманию, что у Интернет есть фатальный недостаток: ну, вы поняли. И это приводит нас к текущему моменту и технологии .NET (произносится как «doughnut (пончик по-нашему)», но по-другому), похожей на Интернет, но с большим количеством пресс-релизов. Главное, что нужно очень четко понимать — .NET исключает DLL Hell. В .NET входит новый язык, C#, (выясняется, что в Active++ Jspresso был фатальный недостаток, от которого он и помер). .NET включает виртуальную машину, которую будут использовать все языки (видимо, из-за фатальных недостатков в процессорах Интел). .NET включает единую систему защиты (есть все-таки фатальный недостаток в хранении паролей не на серверах Microsoft). Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование... примерно на год.

МР>Т.е. если бы развивать WPF далее, нужно было бы
МР>- или принять, что у нас будет единый рендеринг, но чуждый всем (кроме одной) платформам — что-то типа Java Swing / QT / ... Или вложить немаленькие ресурсы в стилизацию, и воспроизведение поведения под все конечные платформы.

Ты не прав. WPF — это идея сделать верстку как в HTML для GUI. Ему не нужен единый стиль контроля для платформ. Те кто выбирает WPF делают это именно, чтобы создавать GUI не похожий на системный. И именно это делает WPF хорошо переносимым. Ведь все контролы написаны с нуля, а не являются оберткой над каким-то системным компонентов. Переносить нужно только низкоуровневый рендерер.

А стилизация в WPF есть из коробки. Только не под платформу, а под задумки дизайнеров. В WPF есть очень мощная система стилей, позволяющая радикально менять внешний вид приложения без изменения кода, как в css и даже круче.

У нас (в Каспере) гуй рисуют дизайнеры в https://www.figma.com. А программисты делают практически идентичный GUI на основании этих макетов.

МР>- если мы хотим поддержки мобильных платформ, то придется еще и радикально перетряхивать всю базовую идеологию и архитектуру: тут и ЖЦ приложения совсем другой и базовые примитивы не такие, ...

Откровенно говоря идея создания приложений которые будет иметь единый GUI как для десктопа, так и для девайсов — бредовая. Как раз добиться того, чтобы библиотека хорошо работала можно. А вот сделать единый дизайн GUI — нет. И как раз лучшей идеей было бы иметь архитектуру WPF, а не Кзамарина. Кзамарин сделан идеологически неверно. Он с одной стороны пытается использовать примитивы платформы, а не рендеринг (как WPF), а с другой тащит свою виртуальную машину, которая создает проблемы при отладке основного кода на девайсах, ну а для iOS вообще может применяться только в режиме AOT, так как iOS не поддерживает джит-компиляции.

Правильная реализация была бы — система верстки на основе WPF и рендеринг нативными средствами, но с кодом конвертируемым в родной для платформы (например, в Java на Андроиде). Но именно такого никто не делает.

МР>В общем, покупка Xamarin, имхо, была логичным шагом и не потому, что WPF чем-то плох. Он просто из другой категории.

Xamarin ужасное говно не пригодное для серьезной разработки. Там совершено аж две ошибки:
1. Свой дижт-компилятор для Андройида.
2. Базирование на примитивах ОС.

Уж лучше HTML + Электрон. За одно в броузере можно будет (потенциально) запускать. Но сразу возникает вопрос, а зачем тогда инсталлируемый десктоп, если оно и в виде веб-странички работает.

МР>Другой вопрос — на сколько сложно/дорого портировать WPF на другие Desktop платформы (на Linux, MacOS, ...) и поддерживать их еще и там.

Вот как я понимаю, это относительно не дорого. Заменяется только рендерер и какие-то там зависящие от платформы. Их явно не много.

МР>Подозреваю, решение не делать это исходно было политическим (зачем конкурентов поддерживать), а сейчас это сложно сделать организационно, ибо от команды WPF осталась только маленькая часть в поддержке. А собрать всех заново — очень дорого, сложно, а главное профит не ясен.

МР>Ну и, скорее всего, такой порт потребует не только переписать рендеринг и переделать взаимодействие с оконной подсистемой, но и поставит вопрос о портировании инструментов: дизайнера, отладчика, профилировщика, ... — а это уже реально дорого, имхо.

Думаю, что в основном рендерер.

Здравствуйте, Михаил Романов, Вы писали:

МР>Ну я бы не стал утверждать, что прямо "похоронили" (в сравнении с реально заброшенным SilverLight, например, или Windows Phone, ...)
МР>Она в режиме поддержки: на Core мигрировали, особо мешающие баги правят, есть какой-то куций, конечно, и в основном ориентированный не на развитие, а на ту же поддержку Roadmap.

Все еще лучше. Её открыли в опенсорс и теперь её поддерживает не только МС по остаточному принципу, но и комьюнити. Мы, например, используем свой форк, а не исходную версию (причем даже не WPF, а всего дотнета и библиотек). В таком виде бояться прекращения поддержки вообще не стоит. Не МС, так комьюнити.

МР>Каких-то серьезных шагов развития нет, это не оспоришь, но, с другой стороны,

А что там развивать? Библиотека самодостаточна. Позволяет легко писать свои контролы и делать верстку. По сути её не особо нужно какое-то развитие. Того что есть хватает для любых извращений.

МР>если принять за базу тезис "десктоп схлопывается", то как-то ожидать серьезных вложений в чисто десктопную технологию было бы странно, имхо.

Я не знаю куда он там схлопывается. Сейчас мода на полувебнутые интерфейсы. Она пройдет как и всё остальное. Для телефонов один фиг принято писать нативные приложения просто потому, что они больше возможностей могут использовать и легче.

МР>Но для тех, кто в свое время сделал ставку на WPF/Windows — это всё равно, хороший момент: ты можешь продолжать и развивать и поддерживать свой продукт, не пытаясь судорожно переписать его на что-то иное.

+1

Особенно для разных государственных и окологосударственных контор, которые уже сделали гуй для Винды и сейчас их толкают к переносу этого всего на Линукс.

K>>Видимо, что-то не так, раз WPF сама Microsoft решила не поддерживать и предпочла купить Xamarin.
МР>Ну они ведь принципиально разные, на сколько я понимаю
МР>- WPF — чистый десктоп и использующий свой рендеринг
МР>- Xamarin.Forms/MAUI — это обертка для нативных библиотек и компонентов

В МС всё определяется борьбой отделов. Каждый должен сделать такой же продукт как у других но другой:

	История программных революций от Microsoft, вкратце
	Сначала были Windows API и DLL Hell. Революцией №1 было DDE – помните, как ссылки позволили нам создавать статусные строки, отражающие текущую цену акций Microsoft? Примерно тогда же Microsoft создала ресурс VERSION INFO, исключающий DLL Hell. Но другая группа в Microsoft нашла в DDE фатальный недостаток – его писали не они! Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием «по месту», при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, возникла MFC решившая все наши проблемы еще раз. Но OLE не собиралась, сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда – и даже включает тщательно разработанную систему версий компонентов, исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток – его писали не они! Они немедленно исправили этот недочет, создав ATL, который как MFC, но другой, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через броузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!). Группа операционных систем громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к Cairo, некой таинственной хреновине, которую никогда не могли даже толком описать, не то, что выпустить. К их чести, следует сказать, что они не представляли концепции «System File Protection», исключающей DLL Hell. Но тут некая группа в Microsoft нашла фатальный недостаток в Java — её писали не они! Это было исправлено созданием то ли J, то ли Jole, а может, и ActiveJ (если честно, я просто не помню), точно такого же как Java, но другого. Это было круто, но Sun засудило Microsoft по какому-то дряхлому закону. Это была явная попытка задушить право Microsoft выпускать такие же продукты, как у других, но другие. Помните менеджера по J/Jole/ActiveJ, стучащего по столу туфлей и говорящего, что Microsoft никогда не бросит этот продукт? Глупец! Все это означало только одно – недостаток внимания к группе ActiveX (или это был COM?). Эта невероятно жизнерадостная толпа вернулась с COM+ и MTS наперевес (может, это стоило назвать ActiveX+?). Непонятно почему к MTS не приставили «COM» или «Active» или «X» или «+» – они меня просто потрясли этим! Они также грозились добавить + ко всем модным тогда выражениям. Примерно тогда же кое-кто начал вопить про «Windows DNA» (почему не DINA) и «Windows Washboard», и вопил некоторое время, но все это почило раньше, чем все поняли, что это было. К этому моменту Microsoft уже несколько лет с нарастающей тревогой наблюдала за интернет. Недавно они пришли к пониманию, что у Интернет есть фатальный недостаток: ну, вы поняли. И это приводит нас к текущему моменту и технологии .NET (произносится как «doughnut (пончик по-нашему)», но по-другому), похожей на Интернет, но с большим количеством пресс-релизов. Главное, что нужно очень четко понимать — .NET исключает DLL Hell. В .NET входит новый язык, C#, (выясняется, что в Active++ Jspresso был фатальный недостаток, от которого он и помер). .NET включает виртуальную машину, которую будут использовать все языки (видимо, из-за фатальных недостатков в процессорах Интел). .NET включает единую систему защиты (есть все-таки фатальный недостаток в хранении паролей не на серверах Microsoft). Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование... примерно на год.

МР>Т.е. если бы развивать WPF далее, нужно было бы
МР>- или принять, что у нас будет единый рендеринг, но чуждый всем (кроме одной) платформам — что-то типа Java Swing / QT / ... Или вложить немаленькие ресурсы в стилизацию, и воспроизведение поведения под все конечные платформы.

Ты не прав. WPF — это идея сделать верстку как в HTML для GUI. Ему не нужен единый стиль контролов для платформ. Те кто выбирает WPF делают это именно, чтобы создавать GUI не похожий на системный. И именно это делает WPF хорошо переносимым. Ведь все контролы написаны с нуля, а не являются оберткой над каким-то системным компонентом. Переносить нужно только низкоуровневый рендерер.

А стилизация в WPF есть из коробки. Только не под платформу, а под задумки дизайнеров. В WPF есть очень мощная система стилей, позволяющая радикально менять внешний вид приложения без изменения кода, как в css и даже круче.

У нас (в Каспере) гуй рисуют дизайнеры в https://www.figma.com. А программисты делают практически идентичный GUI на основании этих макетов.

МР>- если мы хотим поддержки мобильных платформ, то придется еще и радикально перетряхивать всю базовую идеологию и архитектуру: тут и ЖЦ приложения совсем другой и базовые примитивы не такие, ...

Откровенно говоря идея создания приложений которые будет иметь единый GUI как для десктопа, так и для девайсов — бредовая. Как раз добиться того, чтобы библиотека хорошо работала можно. А вот сделать единый дизайн GUI — нет. И как раз лучшей идеей было бы иметь архитектуру WPF, а не Кзамарина. Кзамарин сделан идеологически неверно. Он с одной стороны пытается использовать примитивы платформы, а не рендеринг (как WPF), а с другой тащит свою виртуальную машину, которая создает проблемы при отладке основного кода на девайсах, ну а для iOS вообще может применяться только в режиме AOT, так как iOS не поддерживает джит-компиляции.

Правильная реализация была бы — система верстки на основе WPF и рендеринг нативными средствами, но с кодом конвертируемым в родной для платформы (например, в Java на Андроиде). Но именно такого никто не делает.

МР>В общем, покупка Xamarin, имхо, была логичным шагом и не потому, что WPF чем-то плох. Он просто из другой категории.

Xamarin ужасное говно не пригодное для серьезной разработки. Там совершено аж две ошибки:
1. Свой дижт-компилятор для Андройида.
2. Базирование на примитивах ОС.

Уж лучше HTML + Электрон. За одно в броузере можно будет (потенциально) запускать. Но сразу возникает вопрос, а зачем тогда инсталлируемый десктоп, если оно и в виде веб-странички работает.

МР>Другой вопрос — на сколько сложно/дорого портировать WPF на другие Desktop платформы (на Linux, MacOS, ...) и поддерживать их еще и там.

Вот как я понимаю, это относительно не дорого. Заменяется только рендерер и какие-то там зависящие от платформы. Их явно не много.

МР>Подозреваю, решение не делать это исходно было политическим (зачем конкурентов поддерживать), а сейчас это сложно сделать организационно, ибо от команды WPF осталась только маленькая часть в поддержке. А собрать всех заново — очень дорого, сложно, а главное профит не ясен.

МР>Ну и, скорее всего, такой порт потребует не только переписать рендеринг и переделать взаимодействие с оконной подсистемой, но и поставит вопрос о портировании инструментов: дизайнера, отладчика, профилировщика, ... — а это уже реально дорого, имхо.

Думаю, что в основном рендерер.