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

МР>Альтернативы 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>Я даже не буду комментировать этот бредогенератор

В каком смысле. Вот пример QML:

import QtQuick 2.15
import QtQuick.Controls 2.15

ApplicationWindow {
    width: 300
    height: 200
    visible: true
    title: "QML + JS Example"

    property int clickCount: 0

    Column {
        anchors.centerIn: parent
        spacing: 10

        Text {
            id: counterText
            text: "Нажали " + clickCount + " раз"
            font.pointSize: 14
        }

        Button {
            text: "Нажми меня"
            onClicked: {
                // JavaScript внутри QML
                clickCount++
                if (clickCount % 5 === 0)
                    console.log("Юбилей! " + clickCount + " нажатий")
            }
        }

        Button {
            text: "Сбросить"
            onClicked: resetCounter()
        }
    }

    // JS-функция внутри QML
    function resetCounter() {
        clickCount = 0
        console.log("Счётчик сброшен")
    }
}

Тут видим JS внутри — пусть немного урезанный. Что не так сказал?

Здравствуйте, 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 предложить что-то лучше — посмотрим.