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