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

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

Я как-то на последние лет 7-8 из разработки по desktop просто выпал и у меня как-то сложилось ощущение, что не только WPF практически остановился в развитии (там, имхо, был период, когда вообще стоял вопрос, а Core приложения на нем можно будет писать или всё так и останется на версии 4.8.X!), но и, что логично, всё вокруг — библиотеки контролов, сторонние инструменты, ... — всё было заброшено.
Каково же было моё удивление, когда с год назад я внезапно обнаружил, что вокруг WPF не сказать, что бьет ключом жизнь, но имеется вполне себе не нулевое community, с как минимум поддерживаемыми, а местами — активно развиваемыми библиотеками контролов.

Т.е. я думал что он реально никому не нужен и не интересен, но выглядит что это не совсем так.

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

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

Но на новых проектах 10 раз подумаешь насколько нужно завязываться на эту библиотеку с непонятным настоящим и будущим.

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

WPF изначально выглядел чуждо для Windows и никого это не смущало.
Потом они потратили ресурсы на создание переосмысления под названием UWP, который оказался никому не нужен, ибо даже всё ещё популярная Windows 7 не поддерживалась, не говоря о других платформах.
Теперь у них MAUI, но Microsoft не хочет её поддерживать под Linux.
Могли бы хотя бы вот эту библиотеку купить,.

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

Но в итоге у MS есть WinForms, WPF, MAUI.
На чём из этого я могу сделать десктопное приложение под .NET 8, которое будет работать на всех платформах, где есть .NET 8 (Windows, Linux, MacOS)?

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

А потом удивляемся, что VS Code на вебе сделали, а не десктопных библиотеках.

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

.NET под Linux же завезли, не обязательно при этом под платформу ту же Visual Studio/Blend делать под все платформы с дизайнерами, профиляторами и отладчиками.

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

МР>Ну я бы не стал утверждать, что прямо "похоронили" (в сравнении с реально заброшенным 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 осталась только маленькая часть в поддержке. А собрать всех заново — очень дорого, сложно, а главное профит не ясен.

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

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

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

K>Потом они потратили ресурсы на создание переосмысления под названием UWP, который оказался никому не нужен, ибо даже всё ещё популярная Windows 7 не поддерживалась, не говоря о других платформах.

История была такая. Была такая версия Windows Loghorn. Её гуй планировали сделать на .Net Framework + WPF. WPF изначально создавался именно для этого. Но выкатив альфи (или бэту, уже не помню) в МС поняли, что дотнет и WPF привели к неприемлемому (для тех времён) расходу ресурсов. В результате эту идею быстренько забросили и выпустили Windows Vista. Далее решено было взять верстку WPF, но реализовать её не на .Net Framework, а скрестить с плюсами. Так появился UWP и Windows 8.

K>Теперь у них MAUI, но Microsoft не хочет её поддерживать под Linux.

MAUI — это новое маркетинговое название для Xamarin-а. И под Linux отлично работает. Только на фиг не нужен.

K>Могли бы хотя бы вот эту библиотеку купить,.

Её, как минимум, тогда не было.

K>Но в итоге у MS есть WinForms, WPF, MAUI.
K>На чём из этого я могу сделать десктопное приложение под .NET 8, которое будет работать на всех платформах, где есть .NET 8 (Windows, Linux, MacOS)?

GTK# . Ну вообще не том же Xamarin-е можно. Хотя он и говно. Сделать WPF кроссплатформенной было бы отличным решением.

K>А потом удивляемся, что VS Code на вебе сделали, а не десктопных библиотеках.

А кто удивляется?

Да, МС специально прибивал свои разработки гвоздями к Винде до какого-то времени. Это была идиотская политика.

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

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

K>>Но в итоге у MS есть WinForms, WPF, MAUI.
K>>На чём из этого я могу сделать десктопное приложение под .NET 8, которое будет работать на всех платформах, где есть .NET 8 (Windows, Linux, MacOS)?

VD>GTK# . Ну вообще не том же Xamarin-е можно. Хотя он и говно. Сделать WPF кроссплатформенной было бы отличным решением.

Влад, а что скажешь про Авалонию?

Если что, то у меня есть опыт ее использования

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

VD>GTK# . Ну вообще не том же Xamarin-е можно. Хотя он и говно. Сделать WPF кроссплатформенной было бы отличным решением.

В том и дело, что нет ни одного нормального инструмента для десктопного GUI.
Я не понимаю чего они WPF не допилили под кроссплатформу.
По сути нужно рендер под Linux реализовать, как это видимо сделали в этой библиотеке.
Ну, ещё всякие диалоги выбора файлов кроссплатформенные реализовать, а не из WinAPI предлагать дёргать.
Вместо этого даже для Xamarin не хотят Linux поддерживать, отдали на откуп сообществу и официально о нём не вспоминают.

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

D>Влад, а что скажешь про Авалонию?

Ничего не скажу. Не приходилось использовать.

D>Если что, то у меня есть опыт ее использования

Так поделись.

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

VD>Так поделись.
Присоединюсь!

Был бы очень признателен, если бы кто-то поделился своими впечатлениями.

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

МР>Здравствуйте, VladD2, Вы писали:

VD>>Так поделись.
МР>Присоединюсь!

МР>Был бы очень признателен, если бы кто-то поделился своими впечатлениями.

Во-первых и самое главное, что Авалония работает! Сейчас я в основном разрабатываю на линуксе. Проверял много на винде и совсем чуть-чуть — на маке. Еще запускал в браузере (но там сильно урезанный вариант). По идее можно попробовать запустить на андроиде и iOS.

Сначала, что удивило.

Из простого. Там контролы нужно использовать без наследования. То есть, от них нельзя наследоваться при создании классов. Это мелочь.

Более сложным может быть случай другой. Я уже мог подзабыть детали. Там словил асинхронность обработки событий. Это надо отдельно вспоминать с каким контролом и как. В общем, меняется состояние контрола, и почти тут же завершается поток исполнения, а потом через очередь событий прилетает обработчик события как ни в чем не бывало, как будто начался новый цикл обработки событий. Это если я не забыл деталей. Ладно, во-время поймал и подправил у себя логику. Был несколько удивлен (после WinForms и WPF). Но не могу судить, насколько это распространенный случай. У себя поймал только в одном случае. Кажется, что было связано с событием на изменение какого-то текстового контрола.

Идем далее. Графика 2D пока скудновата. Ну, я подстроился под это.

По размерам бинарников. Бинарники ожидаемо большие. Поэтому пришлось отказаться от идеи публикации браузерного приложения — уж слишком оно огромное для меня.

Из плюсов. Если вы не используете компилятор C# или еще чего такого, то есть высокий шанс создать бинарник с помощью AOT, где бинарник сможет запускаться без требования установки .NET на компьютере клиента, а это очень и очень здорово.

Ну, и напоследок. Есть вопросы к некоторой визуальной громоздкости контролов на экране, но сам факт того, что я могу разрабатывать код на юниксах меня очень и очень радует.

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

D>Во-первых и самое главное, что Авалония работает!
Не поспоришь!

D>Там словил асинхронность обработки событий.
Хм... Интересно...
Я как-то не задумывался об этом вообще (наверное, сказывается ограниченная практика разработки под desktop — ничего сложного) — в каком потоке вызывается обработчик того или иного события.
Обычно, речь идет о том, что любое обращение к контролам должно синхронизироваться в UI-поток, и обработчики событий тоже в нем. А другие детали как-то ускользают.

D>Идем далее. Графика 2D пока скудновата. Ну, я подстроился под это.
Ну мне пока не сильно актуально. Ну и, подозреваю, тут прогресс тормозится еще и из-за поддержки нескольких рендеров/

D>Ну, и напоследок. Есть вопросы к некоторой визуальной громоздкости контролов на экране, но сам факт того, что я могу разрабатывать код на юниксах меня очень и очень радует.
Меня вот это несколько смутило, если честно.
Не знаю как для Linux, а под Windows все приложения на стандартных контролах Avalonia UI, которые я видел, выглядят чужеродно.
Еще я попробовал RoslynPad для WPF и Avalonia и последний вариант был прямо ощутимо глючным (пропадали значения в контролах, что-то не срабатывало, ...) — при том, что он ничего особо не использует. Там основное, это редактор текста, портированный (AvalonEdit)

В любом случае, спасибо за отзыв — их реально не хватает!

Pzz>>А почему сами MS для, например, teams используют подход веб-приложения?
С>Потому что уроды.

а куда, блин, деваться?
мне вот понадобилась аппа со сложным гридом, я беру ту же авалонию, шаг влево — шаг вправо не работает. не сложный грид(это мне самому пилить), просто авалония.
браузеры имеют космическую сложность, если кто-то потратил ресурсы на имплементацию такой штуки — конкурировать уже невозможно.

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

K>Вместо этого даже для Xamarin не хотят Linux поддерживать, отдали на откуп сообществу и официально о нём не вспоминают.

Они не только Linux но и Windows 7 не хотят поддерживать.
А скоро очередь и до 10 подойдет.

Из интересного MauiReactor: An MVU Approach for .NET MAUI

3. True Hot Reload
Thanks to a different separation of concerns, MauiReactor enables superior hot reload capabilities. In MVVM, you typically have View separated from logic (ViewModel) and state (Model), though often developers keep logic and state in a single ViewModel class. In MVU (MauiReactor’s flavor), you have View+Logic separated from Model (State). Keeping state separate from view and logic allows hot reloading the application without losing context. For example, if you have a complex page with text entered in multiple text fields and decide to change some code, when the page is hot-reloaded, the same text remains in the text fields because the state is retained between iterations.

Bringing this all together, here is the typical counter app in MauiReactor.

class CounterPageState
{
    public int Counter { get; set; }
}

class CounterPage : Component<CounterPageState>
{
    public override VisualNode Render()
        => ContentPage("Counter Sample",
            VStack(
                Label($"Counter: {State.Counter}"),
                Button("Click To Increment", () =>
                    SetState(s => s.Counter++))
            )
        );    
}

To put it in perspective, this is the counter in React Native which demonstrates a similar MVU implementation.

import React, { useState } from 'react';
import { View, Text, TouchableOpacity } from 'react-native';

const Counter = () => {
  const [count, setCount] = useState(0);

  return (
    <View>
      <Text>Count: {count}</Text>
      <TouchableOpacity onPress={() => setCount(count + 1)}>
        <Text>+</Text>
      </TouchableOpacity>
      <TouchableOpacity onPress={() => setCount(count - 1)}>
        <Text>-</Text>
      </TouchableOpacity>
      <TouchableOpacity onPress={() => setCount(0)}>
        <Text>Reset</Text>
      </TouchableOpacity>
    </View>
  );
};

export default Counter;

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

K>а куда, блин, деваться?
K>мне вот понадобилась аппа со сложным гридом, я беру ту же авалонию, шаг влево — шаг вправо не работает. не сложный грид(это мне самому пилить), просто авалония.
А можете тоже поделиться опытом: https://rsdn.org/forum/dotnet.gui/8983360.1

Автор: dsorokin
Дата: 26.08 17:45

?

МР>А можете тоже поделиться опытом: https://rsdn.org/forum/dotnet.gui/8983360.1

Автор: dsorokin
Дата: 26.08 17:45

?

я уже запамятовал детали. в целом было впечатление, что есть happy path, описанный в документации, а тем, кто с него свернул обеспечены боль и страдания.

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

VD>MAUI — это новое маркетинговое название для Xamarin-а. И под Linux отлично работает.
MAUI это форк, а значит единый код для всех платформ на нем не возможен. Идиотизм.

VD>Только на фиг не нужен.
Очень нужен. Варианта всего два: "WPF и сиди на винде" или "web UI". Под Avalonia/Uno нет сторонних кечественных библиотек.

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

S> Они не только Linux но и Windows 7 не хотят поддерживать.
S>А скоро очередь и до 10 подойдет.

Это даже на уровне .NET, а не только GUI.
Win 7 с .NET 6 по-моему не поддерживается.

S>Из интересного MauiReactor: An MVU Approach for .NET MAUI

Очередное сомнительное изобретение.
Даже на небольших тестовых примерах как-то уже не очень это всё выглядит.

А что вы думаете насчёт qml в качестве альтернативы?
Кутэ в своё время предоставила хорошие инструменты для миграции с mfc на их виджеты. Qml уже более современная штука, умеет на гпу рендериться, неплохо умеет в виде webassembly в браузере. К тому же Qt сейчас достаточно много инвестирует в то, чтобы сделать биндинги под многие популярные языки.

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

SaZ>А что вы думаете насчёт qml в качестве альтернативы?

Основная претензия — все тот же злополучный JavaScript в основе.

Сейчас лучшее что придумало человечество для формирования UI — это функционально-декларативный подход. Пример: Flutter, Compose MP, Swift UI.

Т.е. обязательное условие — чтобы верстка была не просто декларативной, а позволяла встраивать функции, части интерфейсов выносить в простые функции и вызывать их по месту (которые возвращают дерево контролов/виджетов). Это реально удобнее и проще, чем чистая декларативщина.

Т.е. QML — несколько устарел + JS многие ненавидят. Ну и, получается, две экосистемы — C++ отдельно и скрипты на JS будут отдельно.

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

SaZ>А что вы думаете насчёт qml в качестве альтернативы?
Альтернативы WPF4Linux/XPF?
Если последний работает как заявлено, т.е. "Берем WPF-приложение, подключаем XPF, меняем пару немспейсов и всё волшебным образом работает" — то даже близко не альтернатива.

Я полистал те статьи и глянул на примеры в https://github.com/qt-labs/qtdotnet (собственно, на эту разработку там и ссылаются) — имхо, это может быть решением, когда мы в ситуации:
— у нас есть работающее приложение на WPF, которое продолжает развиваться
— по каким-то причинам принято решение мигрировать на Qt, но:
а) объем миграции огромный и мы понимаем, что это займет очень много времени,
б) останавливать развитие продукта нельзя (т.е. ждать "сейчас все силы на миграцию, а потом уже будем развивать чисто Qt-приложение" не вариант)
в) сил на параллельное развитие 2-х продуктов (WPF и Qt) — нет.

И вот мы начинаем писать новое Qt приложение по схеме:
— переписываем отдельные куски на Qt (там где отделяемый UI) и подключаем их в старое приложение
— когда это возможно — дергаем логику из .Net-кода

Кадавр получается тот еще:
— там, конечно обещали генерацию оберток и простое подключение DTO, но в самих примерах используются "рукопашный" подход с реализацией всяких специфичных интерфейсов (типа IQAbstractListModel). Но, возможно, у них просто всё затянулось — я посмотрел, что код генераторов появился буквально месяц назад, и вообще у них там похоже всё замерло с 2023 года и сейчас вдруг снова проснулось.
— как это отлаживать?
— на сколько хороша инструментальная поддержка? Тут, я конечно очень отстал, и если судить по описанию Qt VS Tools, поддержка QML-проектов в VS довольно хорошая, но я пару лет назад прямо страдал от того, что подсказка кода просто лажала на ровном месте (на стандартных контролах) — и приходилось просто по старинке выдирать фрагмент кода из примера и удалять ненужное.

> К тому же Qt сейчас достаточно много инвестирует в то, чтобы сделать биндинги под многие популярные языки.
Вот это мне показалось куда более интересным и как замена WPF — может даже взлететь.
Но это тоже не альтернатива XPF, это альтернатива самому WPF/Avalonia

Вот только это пока только проект, и когда можно будет увидеть более-менее рабочий результат, увы, не понятно (сроков я там н нашел).

А так, bindings из .Net в Qt делали энтузиасты еще годы назад. Другое дело, что оба известных мне проекта сдохли...
— https://github.com/qmlnet/qmlnet — байдинг к QML
— https://github.com/ddobrev/QtSharp — обертки над API Qt

Возможно, проблема в сложности работы с такими инструментами и может быть ребята из Qt Group​ смогут сделать что-то более человечное.

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

S>...
S>Т.е. QML — несколько устарел + JS многие ненавидят. Ну и, получается, две экосистемы — C++ отдельно и скрипты на JS будут отдельно.

Я даже не буду комментировать этот бредогенератор