В чем фишка Qt Quick

какой практический смысл в Qt Quick?

Ты же сам ответил:

если хочется быстрой разработки, чтобы раз-два и в продакшен

Кажется, что это будет работать медленнее, чем если всё написано сразу на C++

Запуск и отклик ощутимо медленнее, да.

Поэтому возникает вопрос: какой практический смысл в Qt Quick?

Декларативность, быстрое прототипирование интерфейсов.

К сожалению, Qt Quick так и не занял достойной ниши на Desktop’е за пределами KDE. Единственное, где он хоть как-то пользуется спросом – Automotive industry и Kiosk’и, да и то там его теснят и довольно сильно.

На Android и iOS тоже не взлетело. Кто-нибудь знает хоть какое-нибудь большое и успешно-популярное мобильное приложение на Qt Quick в 2023 году? А десктопное? То-то же. Я вот только шкурку Genymotion могу назвать.

Qt Quick слишком рано появился и очень долго был сырым. Идеи были интересные и действительно инновационные, но пока Trolltech, Nokia, Digia и теперь The Qt Company раздуплялись – на рынке появились декларативные SwiftUI, Flutter, React Native, конкурировать с которым он не в состоянии. Да и всякие нишевые Compose Multiplatform и Slint тоже его поджали.

Как мне кажется, Qt Quick создан для мобильных и электроноподобных интерфейсов. А если нужен классический GUI со стандартными виджетами — то Qt Widgets выигрывает.

быстрое прототипирование интерфейсов

Мне почему-то кажется, что здесь Qt Widgets со своим Qt Designer поприятнее может оказаться.

Мне почему-то кажется, что здесь Qt Widgets со своим Qt Designer поприятнее может оказаться.

У Qt Quick насколько я помню был тоже довольно функциональный дизайнер интерфейсов. Но он не прижился, потому что тренд на декларативность с DSL-подобным простым синтаксисом. И не важно что это – описание GUI (Qt Quick, SwiftUI, Flutter), сборки (Gradle, Qbs), или разметки текста (тот же Markdown).

Тот XML-дрист, который выплёвывает Qt Designer (Qt Creator) неудобный, а в Qt Quick у тебя сразу всё наглядно и понятно, в нём очень удобно делать интерфейсы.

Qt Quick слишком рано появился и очень долго был сырым.

Думаю, проблемы были не столько в сырости, сколько в привязке к С++ и невнятной лицензионной политике, разброде и шатании, когда культи переходили из рук в руки.

С одной стороны разработчиков отпугнула необходимость написания бизнес логики на крестах. На джаваскрипте эту самую логику особо не попишешь, ни браузерные API, ни Node.js API не поддерживаются, npm пакеты не работают, да и сам QJSEngine застрял на древнем стандарте ES2016.

С другой стороны отпугнуло неясное тройное лицензирование (супротив простой и понятной MIT у Flutter и React Native), проблемы с соблюдением LGPL лицензии на iOS (поддержка динамической линковки появилась только начиная с iOS 8), поползновения культекомпании к монетизации своих продуктов навроде огораживания LTS релизов и т.д. Уверен, в культекомпании до сих пор рвут волосы на жёппе от того, что нокия в свое время сдуру выкатила культи под LGPL. Они конечно же хотели, чтобы все было как во времена тролльтеха - GPL чисто для KDE и бесплатных тестировщиков и коммерческая лицензия для всех остальных.

Мне почему-то кажется, что здесь Qt Widgets со своим Qt Designer поприятнее может оказаться.

Qt Designer - ну такое себе. Когда у тебя сложная форма с кучей вложенных лейаутов, то добавить новые виджеты - это тот еще пердолинг. Некоторые вещи вообще не настраиваются через дизайнер и надо их руками додрачивать в C++ коде. По памяти могу сказать, что даже в древнем делфи 7 редактор форм был удобнее, хотя за давностью лет могу конечно ошибаться.

У меня многие знакомые разработчики вообще предпочитают создавать виджеты в коде, а не в дизайнере. Говорят, так проще потом рефакторить UI и мержить конфликты в гите.

ЛЮБАЯ декларативщина – зло. Имею Мнение Хрен Оспоришь. Потому что шаг влево-вправо – и досвидос. И статическая типизация её не ловит. А уж если она в качестве «бонусов» даёт ещё и утяжеление с замедлением, то это уже что-то из серии «сплю я плохо, зато мало».

И да, QtWidgets наше фсьо.

Кстати по поводу производительности надо сказать, что в QML рендеринг делается через OpenGL ES, т.е. с полноценным аппаратным ускорением, а вот в виджетах чисто софтварно на CPU. Поэтому если ты делаешь стильно-модно-молодежное приложение со всякими анимациями и эффектами полупрозрачности, то на QML у тебя будут плавненькие анимации в 60 фепесов, а с виджетами будут дергания, тормоза и жор проца.

Qt Quick, ну как бы название говорит само за себя.

Интуитивно кажется, что Quick потянет за собой либо какой-то встроенный интерпретатор JavaScript, либо какой-то хитрый компилятор, но в любом случае добавит накладные расходы на взаимодействие между JavaScript и C++ кодом. Кажется, что это будет работать медленнее, чем если всё написано сразу на C++.

Да, это особенно заметно на слабых ноутбуках.

С другой стороны, если хочется быстрой разработки, чтобы раз-два и в продакшен - это же точно не про C++. Для этого есть Electron или Web в браузере. C++ для GUI, на мой взгляд, имеет смысл выбирать только если хочется максимальной производительности и минимального расхода ресурсов, а сроки разработки не особо важны.

Electron, Quick и им подобные, подходят для простенького софта, для чего-то более серьёзного подойдёт только C/C++, в ином случае на слабом железе будут тормоза, матюки и падения, и мало кто захочет таким пользоваться.

Вижу что Qt пытается запрыгнуть в мобильную разработку, но это тоже как-то странно, когда есть нативные библиотеки, дающие максимальную производительность или Flutter, дающий кроссплатформу.

В топку Flutter, а натив, он и есть натив, со своими особенностями и проблемами.

Поэтому возникает вопрос: какой практический смысл в Qt Quick?

Видимо ориентировались на «стильных модных молодежных» вайтишников, которые успели нормально освоить только веб программирование. Ну и попутно на его основе пилили дизайнер и qbs.

Вижу что Qt пытается запрыгнуть в мобильную разработку

Telegram и 2GIS не просто попытались.

GPL чисто для KDE и бесплатных тестировщиков

Тролль-проприетарщик не палится.

Уверен, в культекомпании до сих пор рвут волосы на жёппе от того, что нокия в свое время сдуру выкатила культи под LGPL.

это разве им мешало выпустить 6ю версию под GPL+Платная ?

это разве им мешало выпустить 6ю версию под GPL+Платная ?

Технически ничего не мешало. Каждый контрибутор в культи подписывает бумажку, которая позволяет культекомпании в любой момент сменить лицензию на любую другую. Но это было бы равносильно самоубийству. Поднялся бы дикий вой и мелкие проприетарщики (а возможно и крупные) начали бы массово валить на электрон или нативные фреймворки. Сходу не припомню примеров успешной смены более пермиссивных лицензий на GPL. Обратно пасту в тюбик не затолкаешь.

Вместо этого в культекомпании решили пойти по другому пути. Теперь они новые аддоны выпускают как правило под GPL+комер, а также переводят уже существующие аддоны на GPL+комер. Можно посмотреть список модулей Qt 6 и полюбоваться на раздел Add-ons available under Commercial Licenses, or GNU General Public License v3. Там давно известные Qt Charts, Qt Virtual Keyboard, Qt Wayland Compositor и прочие аддоны под двойной лицензией. Еще ниже есть раздел с техническими превью, которые релизнутся когда-нибудь позднее. И вот такие штуки как Qt HTTP Server, Qt Graphs, Qt GRPC будут под GPL+комер сразу на релизе.

Если ты когда-либо писал на чём-либо гуй, то вопрос о назначении кьютквика отпадает как только начинаешь его использовать.

Для приложений средней-малой сложности: пишешь логику и view-модель приложения на C++, выставляешь свойства, слоты и сигналы как иерахически структурированные QObject, описывающие объекты предметной области. Всё состояние на 100% хрнится в С++-части.

С++логика и view-модель получается полностью инспектируемая, тривиально покрывается тестами без залезания в чёрный ящик, легко запускается в контексте тевтов без каког-либо GUI.

Но при этом в C++коде вообще ни одного упоминания ничего GUI-ного кроме пары строчек в main.

view объявляешь на qml, структуру виджетов (сбилдится один раз при старте приложения) и привязки к свойства типа выражений

text: Math.max(root_model.left.power_percent,
        root_model.right.power_percent,
        root_model.bottom.power_percent) + "%"

Диайнером не пользовался, писал qml руками.

Qt внутри подписывается на сигналы изменения свойств, причём на всех уровнях - то есть и на изменение свойства root_model.left и на свойство root_model.left.power_percent и тк для всех Пересчитывает+перерисовывает только тот кусок, который соотвествует событиям изменения - при этом логике приложения достаточно изменить Qt-свойство в соотвествии его протоколом.

Я писал на QtQuick только одно приложение, запускал на Rpi3 1GB (linux + тачскрин 800x600). После запуска фигачило 60FPS, тормозов не было.

Минус был найден только один - довольно долгий старт, порядка 15 сек. Второй минус - некоторые вкусные компоненты не под LGPL. Кроме этих двух - минусов не увидел.

Плюсы:

• тестируемый и вообще отвязанный от GUI-классов код view-модели на С++
• Не содержащий бизнес-логики (говно)код на QML, который общается с view-моделью через строго определённое API, то же которое покрывается тестами. Он говнокод, но внутренние инварианты модели нарушить не сможет. И из-за отсутсвия во view состояния - воспроизводимость багов в говнокоде не зависят от предистории. Она визуализирует конкретную мдель или правильно или нет. В отличии от генерации виджетов в функции - нельзя по ошибке сгенрировать виджет только под if, а потом забыть сделать перевычисление списка виджетов, когда он нужен
• Сигналы об изменении свойств дают идеальную логику обновления:
  • не надо явным оразом писать «GUI перечитай такое-то свойства, я тут что-то поменял» - такая подписка делается автоматом.
  • и в GUIи в view-модели пересчитывается-перерисовыается ровно то что менялось, ничего другого. К свойствам, которые не менялись и обращений не будет.
  • для обеспечения такого поведения количество танцев с бубном на уровне ситаксиса очень умеренно - достаточно аккуратно использовать Qt-Property (примитивная макро-шаблоно-магия над C++)

Вцелом - по соотношению сроки/количество_багов/удобство_использования_результата я остался очень доволен qt quick (по сравнению с QtWidgets, а также WPF и WinForms на винде).

Поддерживаю.

С Qt Quick легко сделать компоненты на C++, распихать их по плагинам и комбинировать в коде на QML. Легко создавать кастомные виджеты, переиспользовать куски гуя в нескольких местах. Легко делать моки гуя, в которых все невизуальные компоненты замокаплены, но все гуишные штуки работают: диалоги вызываются, менюшки выскакивают с анимацией и всё такое.

В плане производительности: на работе пишу приложение, которое показывает глобус в 3D, на поверхности всякие аннотации - символы и модели кораблей, полигоны, радарные снимки и прочее. Плюс, выводится до 16 видеопотоков со стационарных камер, смонтированных на кораблях или с дронов, включая один в fullhd. Плюс, кадры видео имеют привязку к координатам, можно спроецировать видеопоток на глобус. И всё это работает на стабильных 60 fps на NVIDIA GTX 1650. И даже на NVIDIA Tegra с парой видеопотоков работает довольно прилично (около 25-30 фпс).

Qt Charts, Qt Virtual Keyboard, Qt Wayland Compositor

бесполезный мусор, не интересно

а вот QString смогут они вернуть под GPL ?

А десктопное?

Viber

Qt Quick не упрощает разработку, т.к. сложное приложение без C++ не напишешь, и придется кроме c++ знать еще qml/js и как взаимодействовать между плюсовой частью и qml.

Кроме того встроенный js приводит к тому, что часть ошибок можно обнаружить только во время выполнения, что плохо.

Однако надо признать, что qml позволяет делать не только нативные интерфейсы на стандартных компонентах а-ля win98/xp, но и вообще любые дизайнерские фантазии (почти). Но это же можно было бы сделать и без такого синтаксиса и без js на плюсах, сделав весь этот функционал на c++ (назвать как-нибудь widgets2).

Telegram и 2GIS не просто попытались.

Telegram под Android никогда не использовал Qt или Qt Quick, насколько я знаю.

А вот 2GIS, действительно, использовал. И очень-очень давно. Сначала у них был собственный порт Qt 4 на Android, который назывался Greenhouse или как-то так, было это лет 10-13 назад, 2GIS тогда выглядел вот так: https://habr.com/ru/articles/113495 и никаким Qt Quick там кстати не пахло, был чистый C++ под JNI.

Потому появился порт на Qt 5, а потом уже они перешли на Qt Quick, вот только сегодняшняя версия 2GIS для Android использует ли Qt или Qt Quick? Что-то сильно сомневаюсь.

Очень обидно было, когда Qt начали проталкивать Qt Quick, не щадя ресурсов на это, и подзабив на виджеты. Занимался коммерческой разработкой двух очень больших десктопных приложений, написанных на Qt, со сложным GUI (предпроизводственная подготовка печатных плат), и отговаривал менеджеров пытаться переводить это всё на Qt Quick.

Qt Quick для мелкого и быстро сделанного.

это тоже как-то странно, когда есть нативные библиотеки, дающие максимальную производительность

Нативные библиотеки на Java писанные? Так они тебе не дадут максимальную производительность. В отличие от Qt, который под ARM, внезапно, компилируется.

или Flutter, дающий кроссплатформу.

Открою тебе секрет: Qt и QML тоже кроссплатформенные. Проект можно собрать хоть под десктоп Mac/Lin/Win, хоть под мобилу Android/IOS/Sailfish. Мало того, мобильный проект можно без проблем на десктопе запускать.

https://www.youtube.com/watch?v=QCQl16apYqQ

Поэтому возникает вопрос: какой практический смысл в Qt Quick?

Один код - куча платформ.

Quick кажется это как Визуальный Уасик, только не визуальный, т.е. для приложек с интерфейсом нарисованным в фотошопе с стиле Windows Media Player только на современный вебовский лад. Кажется, такое всегда востребованно у бизнесов, т.к. такое приложение, с большими яркими контролами как на вебсайте, воспринимается ими как более совершенное/дорогое.

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

вот только сегодняшняя версия 2GIS для Android использует ли Qt или Qt Quick? Что-то сильно сомневаюсь.

А какая альтернатива?

А какая альтернатива?

То, что используют всякие Яндекс.Карты, Google Maps, и ещё сотня подобных приложений.

интерпретатор JavaScript

Там именно компилятор QML в C++ и какие-то байт-коды. Это иной подход нежели чем в GTK, где можно писать те же расширения на JS. Профит в том, что декларативщину писать быстрее чем портянки статически-тупизированного говна, а в итоге скорость сопостапвимая, поэтому QML - это выбор по умолчанию.

порядка 15 сек

Что-то многовато…

А что они используют?

Telegram под Android никогда не использовал Qt

Действительно, спасибо!

только сегодняшняя версия 2GIS для Android использует ли Qt или Qt Quick? Что-то сильно сомневаюсь.

В списке «О программе/Сторонние библиотеки» Qt уже нет. Видимо, что-то своё наваяли.

На андроиде qt и не нужен, там есть react. Ужас да? Любой верстальщик-формощшлеп может штамповать с десяток приложений в месяц. И то java-мир, куда с крестами вход запрещен

Его фишка в том, что там нет нормальных MVC паттернов и код быстро превращается в нечитаемую лапшу из декларативных блоков и вставок на java script.

Воистину никогда нельзя позволять писать императивный код внутри разметки.

Вот в WPF с этим ситуация сильно лучше, хотя немного c# кода навставлять в разметку можно, если захотеть. Но всё равно это не идёт ни в какое сравнение с qt quick.

Согласен, хорошо сформулировано.

Именно это напрягало больше всего - мешанина из кода и определения UI. И приходилось прилагать усилия, чтобы с этим бороться, вместо того, чтобы решать целевую задачу.

Там именно компилятор QML в C++ и какие-то байт-коды

Он только за деньги.

В списке «О программе/Сторонние библиотеки» Qt уже нет. Видимо, что-то своё наваяли.

Сейчас глянул для интереса - действительно нет. Интересно, а раньше они Qt в этом списке вообще указывали или нет? Не далее как в июне этого года у них выходила статья в уютненьком корпоративном бложике на швабре про то, как они используют Qt/QML в андроид приложении. Вряд ли с тех пор они успели дропнуть культи.

https://habr.com/ru/companies/2gis/articles/740054

В 2ГИС Qt используется для мобильного Android-приложения. Под iOS тоже можно писать на Qt, но у нас сложилась отличная команда нативных iOS-разработчиков, поэтому такой необходимости пока нет.

Впрочем надо полагать, что если бы у них сложилась отличная команда нативных Android-разработчиков, то и под андроид Qt нафиг не нужны были бы.

Telegram под Android никогда не использовал Qt
Действительно, спасибо!

Неправильное утверждение. Никогда не использовал QML, а Qt то использовал только в путь.

Его фишка в том, что там нет нормальных MVC паттернов и код быстро превращается в нечитаемую лапшу из декларативных блоков и вставок на java script.

Как только начинаешь писать интерфейс отдельно, модели отдельно, контроллеры отдельно, то сразу видишь нормальное MVC в Qt.

Например, достаточно сконструировать прогу, у которой есть и Qt Widgets интерфейс для десктопа и QML интерфейс для мобилы, то сразу увидишь все достоинства MVC. В Qt.

Name            : telegram-desktop
Version         : 4.11.8-1
Description     : Official Telegram Desktop client
Architecture    : x86_64
URL             : https://desktop.telegram.org/
Licenses        : GPL3
Groups          : None
Provides        : None
Depends On      : hunspell  ffmpeg  hicolor-icon-theme  lz4  minizip  openal  ttf-opensans  qt6-imageformats  qt6-svg  qt6-wayland
                  xxhash  rnnoise  pipewire  libxtst  libxrandr  libxcomposite  jemalloc  abseil-cpp  libdispatch  openssl  protobuf
                  glib2  libsigc++-3.0  glibmm-2.68
Optional Deps   : webkit2gtk: embedded browser features

qt6-imageformats qt6-svg qt6-wayland

Он бы мог и просто зависимости посмотреть

Но у меня такое ощущения, что qt в зависимостях нужен только чтобы показывать иконку телеграма в трее. Надо исходники смотреть, но мне лень

Первое попавшееся:

https://github.com/telegramdesktop/tdesktop/blob/dev/Telegram/SourceFiles/box...

#include <QtGui/QGuiApplication>
#include <QtGui/QClipboard>

Ну значит телеграм «написан на Qt»

Ну значит телеграм «написан на Qt»

А чего в кавычках то? :)

Если используется QGuiApplication, то точно написан на Qt.

Ну там только базовые вещи какие-то используются. Сам-то телеграм - это больше про оригинальный протокол и взаимодействие с ним

Неправильное утверждение. Никогда не использовал QML, а Qt то использовал только в путь.

И как это проверить? Поиск «qt» в файлах распакованного apk не дал удовлетворительных результатов.

Интересно, а раньше они Qt в этом списке вообще указывали или нет?

Да, сам видел. :) Но это было больше 7 лет назад.

Пользуясь случаем, может кто подскажет нормальный туториал по этому самому QML? Как создать проект, как к QML-интерфейсу прикрутить свой «бэкэнд» на Qt/C++, который будет по факту делать работу, а интерфейс на QML чисто отображалка и передавалка в «бэкэнд» данных.

Скачал и собрал Qt6.5, создаёшь там проект Qt Quick Application, получаешь дохреналлион файлов в дереве и хрен пойми, что с этим делать.

https://www.qt.io/product/qt6/qml-book

Пробовал. «Создайте проект», запустите. Запустился? Круто, QML у вас работает, а теперь будем разбирать элементы, которыми строится интерфейс.

Особой информации о том, как устроен сам проект, я не увидел. При этом у меня в дереве проекта половина системы отображается, куча подкаталогов, каталогов, файлов и т.д. И дефолтный «пустой» проект уже содержит в себе некий QML-код, который рисует окно с кнопкой, надписью и всякими эффектами. Куда мне свой код писать? В него? Или отдельно? Как файлы подключать? И т.д.