Здравствуйте, Shmj, Вы писали:
S>Идея замечательная, в свете тенденции юниксификации — проект довольно не плох.
Не знаю как там на практике. Даже в теории это костыль для быстрой миграции уже существующих больших проектов.
Новое на этом делать странно, маленькие тоже проще переписать на чём-то более адекватном, чтобы не лавировать между проблем WPF и этой библиотеки.
S>Но цену вы видели? $46933. Ну ОК, до крыла самолета немного не дотягивает — но кто вообще это сможет купить?
Годовая стоимость одного-двух разработчиков.
S>Такая цена годится разве что для распилов — а все нормальные редкие библиотеки — ну от 1 тыс. долларов продают.
За сколько денег ты портируешь проект на WPF с сотнями окон, десятками юзер-контролов и т.п.?
Ну, вот 10 лет пилится проект, пользователи активно в нём работают и продолжают просить новые функции и различные доработки.
Сколько человеко-лет по-твоему потребуется на перенос всего этого добра на ту же Avalonia и сколько это будет в деньгах?
Что в данном случае будет распилом?
Потратить, допустим, 5 млн. рублей на доработки с этой библиотекой или отделу программистов платить зарплату год (в разы больше денег на это уйдёт) на полное переписывание GUI под другую библиотеку?
S>А эта библиотека могла бы претендовать на массовость, по этому моли бы и начиная от $300 продавать.
Вот и будет распил, что купят библиотеку за $300, а на бумаге в смету внесут портирование на Linux за $100k.
У библиотеки не может быть массовости и век достаточно короток.
Через 5 лет уже всё восребованное портируют и библиотека будет никому не нужна.
Там может и будут продавать за $300, чтобы хоть что-то собрать.
Да и сейчас на главной у них указано:
Малый и средний бизнес
Цена по запросу
На приложение, 1-й год.
Бессрочная резервная лицензия.
Здравствуйте, 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
Вот только это пока только проект, и когда можно будет увидеть более-менее рабочий результат, увы, не понятно (сроков я там н нашел).
Здравствуйте, SaZ, Вы писали:
SaZ>Не, я прекрасно понимаю что нет волшебной таблетки, которая превратит WPF приложение в QML и будет безболезненный переход.
Да я вас понимаю, но конкретно в случае стартового сообщения мы имеем дело с чем-то, подходящим под определение "волшебная таблетка".
Ибо, если ребятам удалось добиться ситуации "99% кода вы переносите просто перекомпилировав ваше приложение с нашими библиотеками, а оставшийся 1% (который не совместим и потребует переписывания), более-менее описан в документации", то мы реально имеем дело с небольшим чудом.
SaZ>Я скорее про ситуацию, когда уже видно, что технологию практически похоронили и точно не будут добавлять фичи, нужные бизнесу (типа полноценной кросс-платформенности). И пора закладывать бюджеты на переезд на что-то более живое.
Ну вот опять же, если говорить о WPF, то ситуация какая-то не очень понятная...
Т.е. с одной стороны да, ждать от Microsoft развития WPF не приходится и кросcплатформы там, скорее всего, не будет.
С другой — поддержка осталась, т.е. как минимум, можно ожидать, что
— в новых версиях Windows (и .Net!) WPF будет работать
— критичные баги будут исправляться (хотя список Issues там огромный, и разгребается, похоже, только самое серьезное)
И в свете этого получается, что вроде как основной камень преткновения — кроссплатформенность. И если не упираемся в неё, то сам факт, что WPF чисто на поддержке — вроде не так и критичен...
Но, нюансов принятия решения будет море, я согласен.
SaZ>А тот же Wine пробовали? Хотя если получится его заюзать, но потом что-то отвалится, то починить будет практически нереально и это неприемлемый риск для бизнеса.
В моей практике — нет.
Как я уже говорил — у меня очень слабый опыт десктоп-разработки, а миграция Web или консольных приложений, это совсем другой спектр задач.
SaZ>Виджеты в Qt достаточно давно стабилизировались, но их основная беда — это CPU рендеринг, отсутствие некостыльных анимаций и слабая поддержка мобильных платформ, что в современном мире не очень хорошо. А после этого qt целиком сосредоточились на embedded/hmi и т.п., ну то есть на той части рынка где крутится энтерпрайз бабло. SaZ>Тем не менее, я считаю QML уже достаточно зрелой технологией для продакшена десктопного и мобильного софта (но так считать я начал только годика полтора назад).
В моем понимании enterprize это немного другое, а именно всевозможные информационные системы, а для них куда важнее (имхо, конечно)
— наличие готовых библиотек контролов (или возможность их дешево разработать/доработать)
— удобный инструментарий для привязки данных
Т.е. дешевая и качественная разработка UI.
Причем, вот сколько не сталкивался, наличие мобильной версии помогает в продажах, но по факту это или специфические сценарии и клиентские приложения (которые от базового клиента отличаться могут разительно). Но я на всезнание не претендую.
SaZ>Делать профилировку всё-таки лучше в QtCreator. Но на моей практике это не сильно часто нужно, при достаточном понимании концепций qt/qml. Хотя и другие тулзы не отстают, включая плагины для CLion/MSVS. SaZ>Да, и Qt инвестируют в файнтюнинг llm моделей, заточенных на qml и разрешают их локальный запуск.
Не, я про более просты вещи — про отладку с целью поиска/исправления багов.
Как будет здесь работать связка .Net + Native + QML?
Например, можно ли будет, отлаживая .Net приложение, посмотреть состояние QML контрола, не прибегая к каким-то ухищрениям?
И в какой среде это можно будет сделать — в VS/QtCreator/...
SaZ>Если честно, я WPF практически не умею. Меня в принципе интересует концептуальный подход к использованию QML в качестве фронтэнда.
Ну я немножко исследовал вариант ".Net + QML", но в тех сценариях я ориентировался на вариант, когда у меня полноценное десктоп приложение на .Net, а QML — просто GUI-библиотека.
Для связки брался QMLNet (открытое, но увы, ныне заброшенное решение).
Увы, впечатления были не самые позитивные после WPF (а уж тем более WinForms): всё неинтуитивно, инструментальной поддержки нет (для .Net нужно использовать одну IDE, для QML — другую), для связки нужно писать тонну кода, причем не в привычном для .Net стиле (не прямая работа со свойствами моделей, а куча методов для их изменения), отладка (в привычном режиме, когда я вижу и свойства объектов и свойства контролов) — не возможна, ...
Смогут ли ребята из Qt предложить что-то лучше — посмотрим.
Здравствуйте, Михаил Романов, Вы писали:
МР>Здравствуйте, VladD2, Вы писали:
VD>>Так поделись. МР>Присоединюсь!
МР>Был бы очень признателен, если бы кто-то поделился своими впечатлениями.
Во-первых и самое главное, что Авалония работает! Сейчас я в основном разрабатываю на линуксе. Проверял много на винде и совсем чуть-чуть — на маке. Еще запускал в браузере (но там сильно урезанный вариант). По идее можно попробовать запустить на андроиде и iOS.
Сначала, что удивило.
Из простого. Там контролы нужно использовать без наследования. То есть, от них нельзя наследоваться при создании классов. Это мелочь.
Более сложным может быть случай другой. Я уже мог подзабыть детали. Там словил асинхронность обработки событий. Это надо отдельно вспоминать с каким контролом и как. В общем, меняется состояние контрола, и почти тут же завершается поток исполнения, а потом через очередь событий прилетает обработчик события как ни в чем не бывало, как будто начался новый цикл обработки событий. Это если я не забыл деталей. Ладно, во-время поймал и подправил у себя логику. Был несколько удивлен (после WinForms и WPF). Но не могу судить, насколько это распространенный случай. У себя поймал только в одном случае. Кажется, что было связано с событием на изменение какого-то текстового контрола.
Идем далее. Графика 2D пока скудновата. Ну, я подстроился под это.
По размерам бинарников. Бинарники ожидаемо большие. Поэтому пришлось отказаться от идеи публикации браузерного приложения — уж слишком оно огромное для меня.
Из плюсов. Если вы не используете компилятор C# или еще чего такого, то есть высокий шанс создать бинарник с помощью AOT, где бинарник сможет запускаться без требования установки .NET на компьютере клиента, а это очень и очень здорово.
Ну, и напоследок. Есть вопросы к некоторой визуальной громоздкости контролов на экране, но сам факт того, что я могу разрабатывать код на юниксах меня очень и очень радует.
я уже запамятовал детали. в целом было впечатление, что есть happy path, описанный в документации, а тем, кто с него свернул обеспечены боль и страдания.
Раз уж тут на сайте рекламируют, то не грех обсудить.
Идея замечательная, в свете тенденции юниксификации — проект довольно не плох.
Но цену вы видели? $46933. Ну ОК, до крыла самолета немного не дотягивает — но кто вообще это сможет купить?
Такая цена годится разве что для распилов — а все нормальные редкие библиотеки — ну от 1 тыс. долларов продают. А эта библиотека могла бы претендовать на массовость, по этому моли бы и начиная от $300 продавать.
Здравствуйте, Quebecois, Вы писали:
Q>Единственное, что приходит в голову — кто-то решил перепродавать бюджетникам ворованный XPF, пока РФ не чешется насчет исков из-за рубежа.
Подозреваю, что да, это XPF, но вполне возможно и не ворованный. И как раз структура сайта, повторяющая XPF, говорит, имхо, в пользу этого варианта (воровали бы — скрывали лучше)
Т.е. я бы скорее предположил, что мы видим некий аналог тех же "Танков" или Abbyy, которые увели всё производство из России/Белоруссии, но создали, якобы никак не связанные с родительскими, компании для продаж и поддержки продуктов на местах. Ну и сами продукты, пришлось "переименовать".
А на сколько я знаю, среди активных разработчиков той же AvaloniaUI было несколько россиян/русскоговорящих (я, правда, с ходу могу вспомнить только Никиту Цуканова, но вроде были и еще ребята).
Поэтому вариант, что было решение для России сделать отдельную ветку и попробовать продавать её в отрыве от Avalonia XPF, мне кажется вполне жизненным.
Здравствуйте, karbofos42, Вы писали:
K>Но в 2025 году начинать разработку на WPF — это по-моему очень странное решение, которое в итоге может привести к необходимости покупки хотя бы этой вот библиотеки.
Не оспаривая этот тезис (я в целом с ним согласен, наверное), хочу тем не менее поделиться наблюдением (для вас, наверное, не новость, а вот я был удивлен и пожалуй что приятно удивлен)...
Я как-то на последние лет 7-8 из разработки по desktop просто выпал и у меня как-то сложилось ощущение, что не только WPF практически остановился в развитии (там, имхо, был период, когда вообще стоял вопрос, а Core приложения на нем можно будет писать или всё так и останется на версии 4.8.X!), но и, что логично, всё вокруг — библиотеки контролов, сторонние инструменты, ... — всё было заброшено.
Каково же было моё удивление, когда с год назад я внезапно обнаружил, что вокруг WPF не сказать, что бьет ключом жизнь, но имеется вполне себе не нулевое community, с как минимум поддерживаемыми, а местами — активно развиваемыми библиотеками контролов.
Т.е. я думал что он реально никому не нужен и не интересен, но выглядит что это не совсем так.
Здравствуйте, Shmj, Вы писали:
S>Раз уж тут на сайте рекламируют, то не грех обсудить.
А почему не в форуме .NET GUI?
S>Идея замечательная, в свете тенденции юниксификации — проект довольно не плох.
Сразу палишься, студент! Идея как раз ПОЛНОСТЬЮ ПРОВАЛЬНАЯ. "Декстоп" в Линуксе — это такая шредингерская сущность, что даже сам Трольвадс признался, что десктоп (за столько лет!!) "не готов" к пользованию "обычным юзером". Т.е. он как бы есть, десятки "оконных менеджеров" и прочей шелухи, а дельного ничего нет.
Любой линукс форум кишит кем угодно, от школоты до админов, но ВСЕ они — продвинутые ойтишнеги. Есессно, заражённые "халявой" опенсорса. КТО И ЗАЧЕМ будет писать для этих гиков "графические приложения"?? Купить их никто не купит, а меценатствовать дураков нет.
S>Но цену вы видели? $46933
Напоминает известный анек про бабку и курицу за $1000.
S> А эта библиотека могла бы претендовать на массовость
У кого? У вечных халявщиков-линуксоидов?
Да и откровенно, WPF — полное г---но. Идея декларативного ГУЯ — превосходна, но её воплощение в виде overengineered piece of sh.... — полная шляпа.
А что не так с архитектурой у WPF? Там ничего такого крамольного в архитектуру не вносили. Все сделано с нуля и не привязано к платформе. К платформе привязана низкоуровневая реализация рендеринга.
K>Все эти волшебные преобразователи — это конечно хорошо, но отношусь скептически.
Я так понял это просто порт библиотеки на другую платформу. Что тут волшебного?
K>Потенциально или откровенные артефакты отрисовки будут или банально под виндой в WPF будет работать виртуализация коллекции в контроле, а в линуксе с этой прослойкой отвалится, сразу создаст миллионы контролов.
K>Хорошо, если найдётся решение, которое будет работать на всех нужных платформах, но скорее всего придётся немного разную разметку/код городить под разные платформы, чтобы оно нормально выглядело и работало.
Это всё домыслы.
K>С десктопными средствами сейчас везде не очень, не модно наверно это.
Ну так наличие еще одного решения не хуже чем его отсутствие?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Михаил Романов, Вы писали: МР>Ну я бы не стал утверждать, что прямо "похоронили" (в сравнении с реально заброшенным 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 осталась только маленькая часть в поддержке. А собрать всех заново — очень дорого, сложно, а главное профит не ясен. МР>Ну и, скорее всего, такой порт потребует не только переписать рендеринг и переделать взаимодействие с оконной подсистемой, но и поставит вопрос о портировании инструментов: дизайнера, отладчика, профилировщика, ... — а это уже реально дорого, имхо.
Думаю, что в основном рендерер.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>GTK# . Ну вообще не том же Xamarin-е можно. Хотя он и говно. Сделать WPF кроссплатформенной было бы отличным решением.
В том и дело, что нет ни одного нормального инструмента для десктопного GUI.
Я не понимаю чего они WPF не допилили под кроссплатформу.
По сути нужно рендер под Linux реализовать, как это видимо сделали в этой библиотеке.
Ну, ещё всякие диалоги выбора файлов кроссплатформенные реализовать, а не из WinAPI предлагать дёргать.
Вместо этого даже для Xamarin не хотят Linux поддерживать, отдали на откуп сообществу и официально о нём не вспоминают.
Здравствуйте, dsorokin, Вы писали:
D>Во-первых и самое главное, что Авалония работает!
Не поспоришь!
D>Там словил асинхронность обработки событий.
Хм... Интересно...
Я как-то не задумывался об этом вообще (наверное, сказывается ограниченная практика разработки под desktop — ничего сложного) — в каком потоке вызывается обработчик того или иного события.
Обычно, речь идет о том, что любое обращение к контролам должно синхронизироваться в UI-поток, и обработчики событий тоже в нем. А другие детали как-то ускользают.
D>Идем далее. Графика 2D пока скудновата. Ну, я подстроился под это.
Ну мне пока не сильно актуально. Ну и, подозреваю, тут прогресс тормозится еще и из-за поддержки нескольких рендеров/
D>Ну, и напоследок. Есть вопросы к некоторой визуальной громоздкости контролов на экране, но сам факт того, что я могу разрабатывать код на юниксах меня очень и очень радует.
Меня вот это несколько смутило, если честно.
Не знаю как для Linux, а под Windows все приложения на стандартных контролах Avalonia UI, которые я видел, выглядят чужеродно.
Еще я попробовал RoslynPad для WPF и Avalonia и последний вариант был прямо ощутимо глючным (пропадали значения в контролах, что-то не срабатывало, ...) — при том, что он ничего особо не использует. Там основное, это редактор текста, портированный (AvalonEdit)
В любом случае, спасибо за отзыв — их реально не хватает!
Здравствуйте, koenig, Вы писали:
K>а куда, блин, деваться? K>мне вот понадобилась аппа со сложным гридом, я беру ту же авалонию, шаг влево — шаг вправо не работает. не сложный грид(это мне самому пилить), просто авалония.
А можете тоже поделиться опытом: https://rsdn.org/forum/dotnet.gui/8983360.1
Компания
НТК Интерфейс
Сфера деятельности
Разработка, внедрение и сопровождение систем АСДУ и АСУ ТП в энергетике.
Проблема
Основное приложение компании НТК Интерфейс, разработанное на графической платформе WPF, успешно работает в ОС Windows.
В последние несколько лет клиенты всё чаще запрашивают поддержку Linux. Подход с разработкой веб-приложения не удовлетворяет требованиям ряда клиентов вследствие:
Технических ограничений платформы.
Недостаточной производительности.
Современных требований безопасности.
Полная переработка кода под Linux на альтернативных платформах (например, Avalonia UI или Uno Platform) требовала значительных ресурсов и времени,
а также не позволяла переиспользовать существующую кодовую базу и проприетарные графические библиотеки, не имеющие кросс-платформенных аналогов.
Решение
Компания выбрала библиотеку WPF4Linux, которая позволила ей в кратчайшие сроки перенести WPF-приложение на ОС Linux без переписывания кода.
Здравствуйте, Pzz, Вы писали:
S>>Раз уж тут на сайте рекламируют, то не грех обсудить. Pzz>Что это, Беримор? И зачем оно вообще такое нужно?
У меня в кои-то веки появилась реклама на RSDN, аж ностальгия пробила. А то висел вечно белый прямоугольник. И рекламируют нечто интересно, но цена как бы сводит все на нет.
Судя по структуре сайта, ребята пытаются перепродать XPF с наценкой в 4 раза.
Причем, делают это под именем, нарушающим торговую марку Microsoft, и через левую фирму-однодневку. Единственное, что приходит в голову — кто-то решил перепродавать бюджетникам ворованный XPF, пока РФ не чешется насчет исков из-за рубежа. Но зачем для этого делать рекламу на полуживом кывте, мне неведомо. В общем, какая-то фигня.
Здравствуйте, Слава, Вы писали:
С>Здравствуйте, Pzz, Вы писали:
Pzz>>А почему сами MS для, например, teams используют подход веб-приложения?
С>Потому что уроды.
Pzz>>А почему сами MS для, например, teams используют подход веб-приложения? B>А какие ЕЩЁ приложения могут написать веб-макаки с 2-недельными курсами "аштиэмэль для чайников"??
Парадокс в том, что для возможности _разбираться в чужом коде_ веб-макак (дорабатывать и править баги) — надо быть математическим гением-краснодипломником.
Друга ищи не того, кто любезен с тобой, кто с тобой соглашается, а крепкого советника, кто полезного для тебя ищет и противится твоим необдуманным словам.
Жми "бомбочку" (автомодерирование).
B>Сразу палишься, студент! Идея как раз ПОЛНОСТЬЮ ПРОВАЛЬНАЯ. "Декстоп" в Линуксе — это такая шредингерская сущность, что даже сам Трольвадс признался, что десктоп (за столько лет!!) "не готов" к пользованию "обычным юзером". Т.е. он как бы есть, десятки "оконных менеджеров" и прочей шелухи, а дельного ничего нет. B>Любой линукс форум кишит кем угодно, от школоты до админов, но ВСЕ они — продвинутые ойтишнеги. Есессно, заражённые "халявой" опенсорса. КТО И ЗАЧЕМ будет писать для этих гиков "графические приложения"?? Купить их никто не купит, а меценатствовать дураков нет.
Там же в case study написано: Разработка, внедрение и сопровождение систем АСДУ и АСУ ТП в энергетике.
Т.е. ПО для юр. лиц, которым нужна поддержка отечественных ОС (AstraLinux и пр.), а не для физ. лиц.
Здравствуйте, karbofos42, Вы писали:
K>Новое на этом делать странно, маленькие тоже проще переписать на чём-то более адекватном, чтобы не лавировать между проблем WPF и этой библиотеки.
Ну мы вот в Касперском WPF во всю используем. Это позволяет делать гуй таким, какой его придумывают дизайнеры без ограничений. Если вот кому-то нужно делать гуй на несколько платформ, то почему бы и нет? Ну или делать гуй для того же Линукса. Как я понимаю родные средства там не очень. Потому все и делают разные веб и полувеб решения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ну мы вот в Касперском WPF во всю используем. Это позволяет делать гуй таким, какой его придумывают дизайнеры без ограничений. Если вот кому-то нужно делать гуй на несколько платформ, то почему бы и нет? Ну или делать гуй для того же Линукса. Как я понимаю родные средства там не очень. Потому все и делают разные веб и полувеб решения.
WPF прибит гвоздями к DirectX и сама Microsoft на него сильно забила, переводить на Linux не стала.
То у них UWP, то MAUI.
Если нужна кроссплатформа, то логично брать библиотеки, которые её изначально заложили в архитектуру.
Все эти волшебные преобразователи — это конечно хорошо, но отношусь скептически.
Потенциально или откровенные артефакты отрисовки будут или банально под виндой в WPF будет работать виртуализация коллекции в контроле, а в линуксе с этой прослойкой отвалится, сразу создаст миллионы контролов.
Хорошо, если найдётся решение, которое будет работать на всех нужных платформах, но скорее всего придётся немного разную разметку/код городить под разные платформы, чтобы оно нормально выглядело и работало.
С десктопными средствами сейчас везде не очень, не модно наверно это.
Здравствуйте, VladD2, Вы писали:
VD>Ну вот за них это сделала сторонняя компания. Замечательно же?
Для потенциальных потребителей замечательно, что есть такой продукт (при условии, что хорошо работает).
Со стороны Майкрософт — это отвратительно, что они очередную технологию похоронили, всех кинули и вся надежда на сторонних разработчиков.
VD>А что не так с архитектурой у WPF? Там ничего такого крамольного в архитектуру не вносили. Все сделано с нуля и не привязано к платформе. К платформе привязана низкоуровневая реализация рендеринга.
Видимо, что-то не так, раз WPF сама Microsoft решила не поддерживать и предпочла купить Xamarin.
VD>Я так понял это просто порт библиотеки на другую платформу. Что тут волшебного?
Судя по схеме с сайта, они библиотеку отрисовки меняют на свою.
Куда вместо DirectX рисуют не написано, вот и волшебство.
VD>Это всё домыслы.
Это опыт использования костылей типа того же Wine. Там тоже просто библиотеки портировали, никакого волшебства.
Да и у них на сайте в единственном кейсе написано:
— Совместно с разработчиками WPF4Linux были выявлены и исправлены небольшие замечания.
— Специфический функционал приложения, такой как поддержка звуков и системных уведомлений, был адаптирован под Linux.
VD>Ну так наличие еще одного решения не хуже чем его отсутствие?
Так я ж не против, пусть занимаются.
Но в 2025 году начинать разработку на WPF — это по-моему очень странное решение, которое в итоге может привести к необходимости покупки хотя бы этой вот библиотеки.
Здравствуйте, karbofos42, Вы писали:
K>Со стороны Майкрософт — это отвратительно, что они очередную технологию похоронили, всех кинули и вся надежда на сторонних разработчиков.
Ну я бы не стал утверждать, что прямо "похоронили" (в сравнении с реально заброшенным SilverLight, например, или Windows Phone, ...)
Она в режиме поддержки: на Core мигрировали, особо мешающие баги правят, есть какой-то куций, конечно, и в основном ориентированный не на развитие, а на ту же поддержку Roadmap.
Каких-то серьезных шагов развития нет, это не оспоришь, но, с другой стороны, если принять за базу тезис "десктоп схлопывается", то как-то ожидать серьезных вложений в чисто десктопную технологию было бы странно, имхо.
Но для тех, кто в свое время сделал ставку на WPF/Windows — это всё равно, хороший момент: ты можешь продолжать и развивать и поддерживать свой продукт, не пытаясь судорожно переписать его на что-то иное.
K>Видимо, что-то не так, раз WPF сама Microsoft решила не поддерживать и предпочла купить Xamarin.
Ну они ведь принципиально разные, на сколько я понимаю
— WPF — чистый десктоп и использующий свой рендеринг
— Xamarin.Forms/MAUI — это обертка для нативных библиотек и компонентов
Т.е. если бы развивать WPF далее, нужно было бы
— или принять, что у нас будет единый рендеринг, но чуждый всем (кроме одной) платформам — что-то типа Java Swing / QT / ... Или вложить немаленькие ресурсы в стилизацию, и воспроизведение поведения под все конечные платформы.
— если мы хотим поддержки мобильных платформ, то придется еще и радикально перетряхивать всю базовую идеологию и архитектуру: тут и ЖЦ приложения совсем другой и базовые примитивы не такие, ...
В общем, покупка Xamarin, имхо, была логичным шагом и не потому, что WPF чем-то плох. Он просто из другой категории.
Другой вопрос — на сколько сложно/дорого портировать WPF на другие Desktop платформы (на Linux, MacOS, ...) и поддерживать их еще и там.
Подозреваю, решение не делать это исходно было политическим (зачем конкурентов поддерживать), а сейчас это сложно сделать организационно, ибо от команды WPF осталась только маленькая часть в поддержке. А собрать всех заново — очень дорого, сложно, а главное профит не ясен.
Ну и, скорее всего, такой порт потребует не только переписать рендеринг и переделать взаимодействие с оконной подсистемой, но и поставит вопрос о портировании инструментов: дизайнера, отладчика, профилировщика, ... — а это уже реально дорого, имхо.
Здравствуйте, Михаил Романов, Вы писали:
МР>Но для тех, кто в свое время сделал ставку на 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 делать под все платформы с дизайнерами, профиляторами и отладчиками.
Здравствуйте, 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 кроссплатформенной было бы отличным решением.
Pzz>>А почему сами MS для, например, teams используют подход веб-приложения? С>Потому что уроды.
а куда, блин, деваться?
мне вот понадобилась аппа со сложным гридом, я беру ту же авалонию, шаг влево — шаг вправо не работает. не сложный грид(это мне самому пилить), просто авалония.
браузеры имеют космическую сложность, если кто-то потратил ресурсы на имплементацию такой штуки — конкурировать уже невозможно.
Здравствуйте, karbofos42, Вы писали:
K>Вместо этого даже для Xamarin не хотят Linux поддерживать, отдали на откуп сообществу и официально о нём не вспоминают.
Они не только Linux но и Windows 7 не хотят поддерживать.
А скоро очередь и до 10 подойдет.
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.
Здравствуйте, VladD2, Вы писали:
VD>MAUI — это новое маркетинговое название для Xamarin-а. И под Linux отлично работает.
MAUI это форк, а значит единый код для всех платформ на нем не возможен. Идиотизм.
VD>Только на фиг не нужен.
Очень нужен. Варианта всего два: "WPF и сиди на винде" или "web UI". Под Avalonia/Uno нет сторонних кечественных библиотек.
А что вы думаете насчёт qml в качестве альтернативы?
Кутэ в своё время предоставила хорошие инструменты для миграции с mfc на их виджеты. Qml уже более современная штука, умеет на гпу рендериться, неплохо умеет в виде webassembly в браузере. К тому же Qt сейчас достаточно много инвестирует в то, чтобы сделать биндинги под многие популярные языки.
Здравствуйте, SaZ, Вы писали:
SaZ>А что вы думаете насчёт qml в качестве альтернативы?
Основная претензия — все тот же злополучный JavaScript в основе.
Сейчас лучшее что придумало человечество для формирования UI — это функционально-декларативный подход. Пример: Flutter, Compose MP, Swift UI.
Т.е. обязательное условие — чтобы верстка была не просто декларативной, а позволяла встраивать функции, части интерфейсов выносить в простые функции и вызывать их по месту (которые возвращают дерево контролов/виджетов). Это реально удобнее и проще, чем чистая декларативщина.
Т.е. QML — несколько устарел + JS многие ненавидят. Ну и, получается, две экосистемы — C++ отдельно и скрипты на JS будут отдельно.
Здравствуйте, Shmj, Вы писали:
S>... S>Т.е. QML — несколько устарел + JS многие ненавидят. Ну и, получается, две экосистемы — C++ отдельно и скрипты на JS будут отдельно.
Здравствуйте, Михаил Романов, Вы писали:
МР>Альтернативы WPF4Linux/XPF? МР>Если последний работает как заявлено, т.е. "Берем WPF-приложение, подключаем XPF, меняем пару немспейсов и всё волшебным образом работает" — то даже близко не альтернатива.
Не, я прекрасно понимаю что нет волшебной таблетки, которая превратит WPF приложение в QML и будет безболезненный переход. Я скорее про ситуацию, когда уже видно, что технологию практически похоронили и точно не будут добавлять фичи, нужные бизнесу (типа полноценной кросс-платформенности). И пора закладывать бюджеты на переезд на что-то более живое.
Немного оффтоп, но со мной тут приключилась одна история. Года 2-3 назад настойчиво звали лидом на один проект, где стек был Cpp20 + MFC, мол у нас всё на мфц заточено и отлажено. Подписал NDA, показали код, после собеса сделали оффер, но я отказался, потому что понимаю, что буду деградировать занимаясь поддержкой этого динозавра и со временем стану бесполезен на рынке. Тем более что зарплату предлагали вполне себе среднюю для должности. И вот недавно они опять пришли ко мне, но оффер был сразу в два раза выше. И я понимаю, что таких денег мне и близко нигде платить не будут. Но я всё равно отказался. А бизнес был категорически против миграции на современные платформы того, что работает. Даже не смотря на то что уже несколько лет в бэклоге у них есть тикеты про поддержку highdpi и прочие.
Я всё к тому, что со временем трудозатраты на поиск программистов и поддержку решения могут перевесить рефакторинг продукта с переездом на новые технологии. Но это отдельная большая тема, потому что если в проекте изначально забивали на нормальное разделение бизнес и гуи логики, то отрефакторить может быть дороже чем переписать с нуля.
МР>Я полистал те статьи и глянул на примеры в https://github.com/qt-labs/qtdotnet (собственно, на эту разработку там и ссылаются) — имхо, это может быть решением, когда мы в ситуации: МР>- у нас есть работающее приложение на WPF, которое продолжает развиваться МР>- по каким-то причинам принято решение мигрировать на Qt, но: МР>а) объем миграции огромный и мы понимаем, что это займет очень много времени, МР>б) останавливать развитие продукта нельзя (т.е. ждать "сейчас все силы на миграцию, а потом уже будем развивать чисто Qt-приложение" не вариант) МР>в) сил на параллельное развитие 2-х продуктов (WPF и Qt) — нет.
А тот же Wine пробовали? Хотя если получится его заюзать, но потом что-то отвалится, то починить будет практически нереально и это неприемлемый риск для бизнеса.
МР>И вот мы начинаем писать новое Qt приложение по схеме: МР>- переписываем отдельные куски на Qt (там где отделяемый UI) и подключаем их в старое приложение МР>- когда это возможно — дергаем логику из .Net-кода
Да, классическая миграция. Недавно участвовал в проекте, который долго переводили с mfc на qt и там до сих пор остались очень костыльные слои совместимости. Но проект таки переехал (один большой редактор достаточно известного игрового движка).
МР>Кадавр получается тот еще: МР>- там, конечно обещали генерацию оберток и простое подключение DTO, но в самих примерах используются "рукопашный" подход с реализацией всяких специфичных интерфейсов (типа IQAbstractListModel). Но, возможно, у них просто всё затянулось — я посмотрел, что код генераторов появился буквально месяц назад, и вообще у них там похоже всё замерло с 2023 года и сейчас вдруг снова проснулось.
Виджеты в Qt достаточно давно стабилизировались, но их основная беда — это CPU рендеринг, отсутствие некостыльных анимаций и слабая поддержка мобильных платформ, что в современном мире не очень хорошо. А после этого qt целиком сосредоточились на embedded/hmi и т.п., ну то есть на той части рынка где крутится энтерпрайз бабло.
Тем не менее, я считаю QML уже достаточно зрелой технологией для продакшена десктопного и мобильного софта (но так считать я начал только годика полтора назад).
Всякие IQAbstractListModel это тоже отдельная тема. В qt своё видение паттерна mvc, но они его уже лет 20 шлифуют. И со своей колокольни я могу сказать что он достаточно удачный для работы с большими объёмами данных. Опять же, при корректной реализации. Видел недавно что из-за тяп-ляп подхода просто при наведении мышки на элемент дерева делалось около 8 обращений к хэшмапе на 50к элементов. А потом были вопросы типа "почему лагает".
МР>- как это отлаживать? МР>- на сколько хороша инструментальная поддержка? Тут, я конечно очень отстал, и если судить по описанию Qt VS Tools, поддержка QML-проектов в VS довольно хорошая, но я пару лет назад прямо страдал от того, что подсказка кода просто лажала на ровном месте (на стандартных контролах) — и приходилось просто по старинке выдирать фрагмент кода из примера и удалять ненужное.
Делать профилировку всё-таки лучше в QtCreator. Но на моей практике это не сильно часто нужно, при достаточном понимании концепций qt/qml. Хотя и другие тулзы не отстают, включая плагины для CLion/MSVS.
Да, и Qt инвестируют в файнтюнинг llm моделей, заточенных на qml и разрешают их локальный запуск.
>> К тому же Qt сейчас достаточно много инвестирует в то, чтобы сделать биндинги под многие популярные языки. МР>Вот это мне показалось куда более интересным и как замена WPF — может даже взлететь. МР>Но это тоже не альтернатива XPF, это альтернатива самому WPF/Avalonia
Если честно, я WPF практически не умею. Меня в принципе интересует концептуальный подход к использованию QML в качестве фронтэнда.
Знаю что в одной компании здорово оптимизировали воркфлоу. На фронтэнде перешли с дексктопного клиента на практически голый qml + QtGrpc который собирался в wasm, бэкэнд — grpc плюсы и т.п. Отказались от хранения данных в git, сделали клиент-серверную архитектуру. Полностью выкинули шаги по сборке десктопа на CI потому что все всегда имели свежую версию редактора в браузере. И это очень существенно ускорило многие процессы.
МР>Вот только это пока только проект, и когда можно будет увидеть более-менее рабочий результат, увы, не понятно (сроков я там н нашел). МР>А так, bindings из .Net в Qt делали энтузиасты еще годы назад. Другое дело, что оба известных мне проекта сдохли... МР>- https://github.com/qmlnet/qmlnet — байдинг к QML МР>- https://github.com/ddobrev/QtSharp — обертки над API Qt МР>Возможно, проблема в сложности работы с такими инструментами и может быть ребята из Qt Group смогут сделать что-то более человечное.
Да, надеюсь что-то получится. Я в своём пет проекте использую userver+grpc+postgresql+boost+qt, нативные клиенты под все платформы (win/nix/mac/ios/android).
Здравствуйте, SaZ, Вы писали:
S>>... S>>Т.е. QML — несколько устарел + JS многие ненавидят. Ну и, получается, две экосистемы — C++ отдельно и скрипты на JS будут отдельно.
SaZ>Я даже не буду комментировать этот бредогенератор
Напоминает известный анек про бабку и курицу за $1000. 
