QML (QtQuick) ужасно сырой, популярность набирает слабо, хотя в качестве быстрого прототипирования интерфейсов ему нет равных.

PyQt/Qt Widgets (виджеты на C++) адекватны лишь на Desktop'ных платформах.

Есть ли смысл учить PyQt или QML? Или остаться на плюсах?

А что там учить, тем более, если __уже__ имел опыт работы с Python? Да, PyQt это враппер. Но вкупе со знанием Qt и Python ты освоишь всё довольно быстро.

Под Линем есть траблы, под Андроид вообще пару приложений.

Да, с QML пока всё печально. Хотя для Android недавно появились адекватные контроллы, например. Разрабатывать приложения на нём легко, но технология вряд ли станет популярной, несмотря на все усилия The Qt Company.

Есть ли смысл учить PyQt или QML? Или остаться на плюсах?

Останься на плюсах/PyQt, если будешь разрабатывать для десктопной платформы. Если для Android, потыкай палочкой QtQuick/QML. Но не забывай, что нативные Java-приложения будут для платформы Android предпочтительнее.

Там особо вообще нечего учить. То есть вообще. Пара-тройка вечеров и ты уже знаешь PyQt и QtQuick, раз уже имел возможность работать с фреймворком Qt. В QML вообще главное понять общую концепцию и посмотреть пару примеров.

У тебя хоть какой-то пруф будет, про то, что с QML всё печально, или так, ОБС?

У тебя хоть какой-то пруф будет, про то, что с QML всё печально, или так, ОБС?

Под какую из платформ или в общем?

Если брать в общем, то количество программ на QtQuick/QML, относительно программ на QtWidgets говорит само за себя. Увы, это печальный факт.

Если брать относительно платформ.

Android, приложения: Единственные юзабельные и популярные приложения на QtQuick/QML известные мне и присутсвующие в Google Play, это QML Creator и iStodo (не уверен кстати, что он на QtQuick/QML). При этом они выполнены на кастомных контролах, то есть не соответствует родному интерфейсу Android. А контролы, мимикрирующие под родной интерфейс Android были введены совсем недавно (Qt 5.4.0 кажется?) и ещё не были мной раскушены. Вообще у QtQuick/QML-приложений на Android больше всего меня удручает их слишком долгий запуск. И вряд ли что-то с этим можно сделать, учтивая ~10 MB нативных *.so'шек, которым необходимо загрузиться в память.

Android, игры: Самой известной игрой, построенной на технологии QtQuick, является Google'вский VoltAir, так же доступный в Google Play. Все остальные QtQuick игры — это поделки уровня Flappy Bird и недостойны внимания. В принципе, VoltAir хорошая казуальная игрушка, но лично у меня были с ней проблемы: на моём устройстве отсутствовали некоторые крутые эффекты, такие как частицы рядом с подбрасывающими тебя кратерами (они просто не отображались). Видимо в Google протестировали игру только для Nexus'ов. Ну и да, производительность и загрузка процессора:

Google тоже попробовали на Qt'e игрушку написать — VoltAir. Если внимательно почитать все ридми, то можно заметить, что производительностью они не особо довольны, как и загрузкой ЦП. Для игр тяжеловата обвязка в общем…

(с) QtRoS

Если брать технологию Qt Quick в то время, когда она только начала развиваться и была под крылом Nokia, то можно заметить, насколько это было производительное и легкое решение. В Nokia нехило так налегли на оптимизацию, ведь Qt Quick должен был работать на слабых Symbian-устройствах. Увы, Nokia рипнулась, а Qt перешёл к Digia. В Qt 5 технология Qt Quick стала куда как прожорливее и тормознее, хотя, конечно, функциональность её значительно увеличилась. Но, увы, та легкость и быстродействие QtQuick-формочек из Qt 4.8, остались в прошлом.

Linux: Из популярных и известных мне QtQuick/QML приложений я знаю только cool-retro-term. Это очень, очень тяжелое приложение, жрущие CPU, с массой глюков в части интерфейса (посмотрите окно настроек, к примеру). Иногда шлю туда репорты.

Windows: Популярных приложений на QtQuick/QML я вообще не знаю. Но у рассматриваемых примеров, идущих в комплекте с Qt, есть несколько фатальных недостатков. Во-первых это то, что QtQuick в Qt5, в отличие от QtQuick в Qt4 (Qt4 мог в нативный рендеринг на GDI) умеет в рендеринг только через OpenGL|ES/OpenGL, поддержка которого в Windows удручающая. По дефолту в Windows (по-крайней мере в Windows 7) идёт только OpenGL 1.1 прямиком из 1997-го года:

PPSSPP 1.0 (комментарий)

Соответственно на офисных машинках ваше QtQuick-приложение работать не будет или будет работать коряво. Вот у меня есть старый ноут Lenovo G560e с встроенным Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller, для которого производитель видеочипа выпустил версию драйверов с поддержкой OpenGL 2.0 (минимальный OpenGL для Qt Quick), и казалось бы, всё должно работать нормально, ан нет: в половине Qt Quick приложений бьются напрочь шрифты и иногда текстуры так, что пользоваться приложением невозможно вовсе. Поддержка OpenGL большинством вендоров железа в Windows удручающая. К счастью, в дистрибутивах GNU/Linux такой проблемы нет и там отображение шрифтов и текстур работает корректно. Для решения этих проблемы с QtQuick в Windows, The Qt Company советует использовать костыли и подпорки в виде ANGLE. То есть схему: QtQuick app -> OpenGL|ES -> ANGLE -> DirectX. Соответственно, при таком подходе QtQuick-приложение зависит аж от библиотек DirectX (как игра), который нужно тянуть с собой, несчитая ANGLE. В Qt 5.5 нам обещают динамачиский выбор системы рендеринга, позволяющий хоть как-то сократить количество костылей и подпорок. Это печально и такой проблемы в Qt 4.8 не было, так как он мог в нативный рендеринг на всех платформах. Будет ли какой-либо адекватный разработчик мучаться с этими костылями для деплоя и совместимости? Сомневаюсь. Потому и лидируют QtWidgets-приложения.

Я буду только рад, если ты распишешь про хорошо работающие приложения на QtQuick/QML и опровергнешь мою точку зрения. Но пока — это всё сырое. И улучшения вряд ли предвидятся.

На плюсах очень медленно писать

Приведи пример кода на питоне, который тебе медленно писать на плюсах.

Android, приложения: ... iStodo (не уверен кстати, что он на QtQuick/QML). При этом они выполнены на кастомных контролах, то есть не соответствует родному интерфейсу Android...

Backend на плюсах, интерфейс на QML. Контролы кастомные только в плане «их поставляла не Digia», при этом они соответствуют родному интерфейсу Android Holo.

Вон 2Gis новую версию Android приложения написал на QML, но пока не выпускает, потому как работает над оптимизацией.

Я сейчас по работе пишу приложение в стиле Material Design, то есть будет соответствовать родному интерфейсу, но уже пятой ветки (в 5.4 пока стиль только для четвертой).

Еще вроде в одной Питерской конторе серьезно пишут p2p чат на QML.

Вообще у QtQuick/QML-приложений на Android больше всего меня удручает их слишком долгий запуск. И вряд ли что-то с этим можно сделать, учтивая ~10 MB нативных *.so'шек, которым необходимо загрузиться в память.

Проблема скорее в компиляции всех компонентов каждый раз при запуске, возможно прекомпилер из платной поставки Qt сможет в разы улучшить ситуацию.

P.S. При всем этом писать сложные настольные приложения все равно проще, быстрее и правильнее на старых добрых Widgets.

BlackBerry? Нет, не слышал. Sailfish? UbuntuPhone? Маргиналы какие-то, наверное. Также, как и разработчики go-qml (да и никто же на go не пишет, любой аналитик уровня ЛОР скажет). Про мучения с OpenGL и ANGLE, ну я тебе сочувствую. У меня (проприетарная софтинка на QML для достаточно крупного международного концерна) уже работает динамический выбор рендеринга, в том числе софтварного (llvmpipe). Единственный косяк Quick2, который мне известен, это то, что на винфонах без квиккомпайлера адские тормоза. Это есть такой момент, да. А так, QML вполне созрел и готов к продакшену, ИМХО.

Не получу прироста в скорости разработке ГУИ

qt-designer

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

Потому что вот:

some platform versions such as iOS (version 7 and earlier) or Windows RT do not permit the dynamic generation of machine code. As a fallback QML provides an interpreter to allow for the full use of QML, but it comes at the expense of a longer execution time.

в основном согласен с EXL - QML сыроват архитектурно (но чертовски прикольный для прототипиования интерфейсов), багов тоже хватает (например в дебаге не грузит больше одного синглтона из qmldir), есть откровенно неожиданные гадости, типа невозможности использовать LocalStorage в WorkerScript. И тем не менее, я тут тоже упираюсь и делаю поделки для Android (пока не релизился)

Кстати, рекомендую обратить внимание на https://github.com/papyros/qml-material оно только 0.1 и тоже сыровато, но вполне неплохо, можно пользовать и конечно же контрибьютить.

А в целом - если ты собрался на биржи, то там и смотри что более востребовано.

Мы заюзали QML/5.3 в проекте, который сейчас пишем. Все пока отлично, даже производительность лучше, чем QWidgets. Use-case - кастомный гуй Windows/Linux с динамически обновляющимися данными (40-70 FPS).

BlackBerry? Нет, не слышал.

потому что ты нищеброд ходячий, обамазанный андроидным гумусом

ну ты и идиот

Холивар?

Я спрашивал у знакомого с 11 летнем стажем в плюсах и годичным в Питоне, он тоже согласился.

Хмм, пару вечеров

Спасибо, за разъяснения!

Я спрашивал у знакомого с 11 летнем стажем в плюсах и годичным в Питоне, он тоже согласился.

А есть ли у него опыт работы с PyQt и разработки сложного GUI собс-но на Qt? Потому я и попросил пример кода.

Еще вроде в одной Питерской конторе серьезно пишут p2p чат на QML.

А кто такие, если не секрет?

А кто такие, если не секрет?

IT_DEV_SPB