Сообщение Re[3]: QML? от 28.08.2025 16:03
Изменено 28.08.2025 16:22 SaZ
Re[3]: QML?
Здравствуйте, Михаил Романов, Вы писали:
МР>Альтернативы 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 сейчас достаточно много инвестирует в то, чтобы сделать биндинги под многие популярные языки.
МР>Вот это мне показалось куда более интересным и как замена 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).
МР>Альтернативы 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 сейчас достаточно много инвестирует в то, чтобы сделать биндинги под многие популярные языки.
МР>Вот это мне показалось куда более интересным и как замена 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).
Re[3]: QML?
Здравствуйте, Михаил Романов, Вы писали:
МР>Альтернативы 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).
МР>Альтернативы 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).