LINUX.ORG.RU

Qt5: виджеты vs QML

 , ,


1

2

Всем привет! Активно изучаю Qt5, накупил литературы. Есть грандиозные планы на разработку нескольких интерфейсов, в том числе - переписывание интерфейса пары нужных мне программ с wxWidgets на Qt. И задался вопросом - на чём лучше реализовывать GUI - обычных виджетах Qt5, или QML? В сети нашёл лишь плюсы QML в сравнении с виджетами, как простота написания, читабельность, аппаратное ускорение отрисовки. Стало быть у виджетов всё наоборот? Прошу опытных Qt-девелоперов вкратце рассказать о плюсах и минусах виджетов и QML.

простота написания, читабельность

Распространяется только на веберов после всяких ЯваСкриптов и CSS. Обычные программисты блюют от вида QML.

Stahl ★★☆
()

Виджеты — стабильность, проверенность временем, предсказуемость, невозможность рисовать за пределами границы виджета. QML — анимации, свистелки-перделки, декларативное описание гуя. Покажи скриншоты того, что хочешь получить как результат.

fluorite ★★★★★
()
Ответ на: комментарий от RazrFalcon

Для десктопа - Widgets, для мобилок - QML.

Сейчас половина KDE на QML, да и многий софт на нём переписывают (например Kdenlive). Вот я и подумал - раз его тащат на десктоп, значит есть в этом какой-то смысл?

Sunderland93 ★★★★★
() автор топика
Ответ на: комментарий от Stahl

После гуёв на HTML+CSS, QML как бальзам на душу. А уж с возможностью в любой момент подключить плюсы — просто пушка.

fluorite ★★★★★
()
Ответ на: комментарий от robus

Ну, этот ад не предназначен для чтения. Как и вообще любой машинногенерируемый код.

Stahl ★★☆
()
Последнее исправление: Stahl (всего исправлений: 1)
Ответ на: комментарий от fluorite

После гуёв на HTML+CSS, QML как бальзам на душу.

Ну я же говорю — для веб-программистов.
А для обычных программистов что то, что то — говно из одной бочки.

Stahl ★★☆
()
Ответ на: комментарий от fluorite

Обычные виджеты?
Много параметров? Их всегда можно обернуть кодом, их легко изменять/создавать/удалять в реалтайме.
QML же это огромное количество CSS-like писанины.

Stahl ★★☆
()

Аппаратное ускорение от qml никак не зависит.

anonymous
()
Ответ на: комментарий от Sunderland93

Первый пофиг на чём делать, сделай два, ты ж в образовательных целях :) Второй на QML проще чисто из-за прозрачности и размещения элементов.

fluorite ★★★★★
()
Ответ на: комментарий от Sunderland93

Да, ты прав. Первый лучше делать на Qt Widgets. А свистопердячий PPSSPP GUI на QML. Хотя у них собственный легковесный тулкитик там.

EXL ★★★★★
()
Ответ на: комментарий от robus

Этот xml не предназначен для редактирования. Так что без разницы.

RazrFalcon ★★★★★
()
Ответ на: комментарий от fluorite

QPainter и понеслась. Дизигн любой сложности без боли.

RazrFalcon ★★★★★
()
Ответ на: комментарий от Sunderland93

Нет. Плазма это от силы 20%. И учитывая какая она кривая, лучше бы на виджетах писали.

RazrFalcon ★★★★★
()
Ответ на: комментарий от fluorite

Второй на QML проще чисто из-за прозрачности и размещения элементов.

Шта? Виджеты по умолчанию прозрачны, если что.

RazrFalcon ★★★★★
()
Последнее исправление: RazrFalcon (всего исправлений: 1)
Ответ на: комментарий от fluorite

Отваливается если нет композитора. И это нужно только для главного виджета, ака системного окна. Для дочерних виджетов не нужно.

RazrFalcon ★★★★★
()
Ответ на: комментарий от Sunderland93

Который может рисовать через Qt и SDL, правильно?

Не совсем так. Насколько я могу судить, там тупо GUI сделан на OpenGL (OpenGL ES): https://github.com/hrydgard/ppsspp/blob/e17772b58d647ed73fc7c177cdc4feaecb938...

Поэтому нет разницы, что именно выбрать в качестве «блиттера»: SDL, Qt, WinAPI, GLSurfaceView (Android), GLKView (iOS) и т. д., главное чтобы в ядро PPSSPP из выбранного API прокидывались необходимые ивенты: нажатия на кнопки, ресайз окна, возюкание пальцами по экрану, движение курсора мышки и т. д.

EXL ★★★★★
()
Ответ на: комментарий от fluorite

а потом люди вот такое городят.

Вот, к примеру, Telegram for Desktop. Это приложение можно было бы без труда написать на QML/QtQuick. Даже более того, для этого приложения как нельзя лучше подходит QtQuick. Но если посмотреть в исходный код, то можно офигеть, сколько там возни с QPainter и прочим. Нагородили там такого, что ужас.

Однако, видимо были на то причины.

Немного не по теме. Помню, ты реквестировал QML в продакшене, вот же он.

Круто. Хотя, это не совсем похоже на десктопное приложение:

http://esxi.z-lab.me:666/~exl_lab/screens/qml_desktop_app.png

Я хотел бы примеров каких-нибудь редакторов, IDE или мессенджеров на QtQuick. Есть такие в продакшен-природе?

EXL ★★★★★
()
Ответ на: комментарий от EXL

Я вообще не знаю никаких новых редакторов, IDE или мессенджеров, если честно. А что значит — не похоже? Написано для десктопа и работает на десктопе, давай тогда определение «настольного приложения». Когда telegram писали, разве был quick2?

fluorite ★★★★★
()

Активно изучаю Qt5, накупил литературы.

Надеюсь, не Шлее. Вообще, для изучения Qt лучше читать её документацию и смотреть на примеры Qt-приложений.

, как простота написания

Только интерфейсов. Как только начинается логика, так начинаются Js-костыли или склеивание соплями QtQuick-кода с C++.

читабельность

Только если в QtQuick-приложении строго следуют декларативной парадигме и кладут логику отдельно. Но из того, что я видел, часто всё это перемешивают и читабельность ухудшается в разы.

аппаратное ускорение отрисовки

Аппаратное ускорение отрисовки это сила и слабость QtQuick на всех платформах. Когда железо имеет хорошие OpenGL-драйвера, то всё работает просто отлично. Но как только железо начинает отличаться от тестовых стендов Qt-разработчиков — тут-то и начинается огромная куча проблем и постоянные косяки в виде побитых или мерцающих текстур, чёрных окошек и прочих глюков. На некоторых системах эти проблемы завязывают на жуткие костыли вроде трансляции OpenGL ES -> ANGLE -> DirectX, иначе, например, приложения не работают через RDP. В конце-концов, была запилена и программная отрисовка для QtQuick-приложений: http://doc.qt.io/QtQuick2DRenderer/, прямо как в Qt 4.

вкратце рассказать о плюсах и минусах виджетов и QML.

Qt Widgets:
+ Проверенное решение, 99% Qt-приложений используют именно их;
+ Скорость работы и отзывчивость интерфейсов;
+ Возможность проектирования сложных GUI по типу: https://www.hex-rays.com/products/ida/pix/idalarge.gif;
+ Поддержка в некоторых IDE и системах сборки;
+/- Приелимая мимикрия под стандартные системные контролы, но в некоторых системах имеются проблемы с внешним видом (например, в macOS);
- Очень редко обновляются и практически не развиваются, из последнего добавлена только поддержка HiDPI;
- The Qt Company может вскоре отказаться от развития и поддержки QtWidgets (вспоминаем QtScript, QtWebkit и пр.);
- Из-за MOC и прочих надкомпиляторов большие QtWidgets-проекты компилируются достаточно долго;
- На Android и iOS выглядят как говно и работают точно так же.

QML/Qt Quick:
+ Очень быстрое прототипирование и последующая разработка интерфейсов;
+ Для написания GUI лучший синтаксис ever;
+ Создание красивых анимаций из коробки без всякого красноглазого матанзадротства;
+ Легкая кастомизация уже существующих GUI-элементов;
+ Идеальный выбор для Kiosk- и Mobile- приложений, для анимированных GUI;
+ Лучшая (чем у QtWidgets) кросс-платформенность;
+ Можно встраивать виджетами в QtWigdets;
- Поддержки родных системных контролов по сути нет. То что есть — ужас и срам. Тулкит хоть и поддерживает кое-какие HIG'и (Material, Simple и др.), но является инородным абсолютно везде;
- Сообщество очень небольшое и мелкое, какие-то возникающие проблемы нагуглить сложно, приходится писать в рассылку или в прочие Developer'ские каналы. C QtWidgets или Electron (конкурент QtQuick) — значительно легче получить помощь;
- Для написании сложной логики нужно будет делать Js или C++ вставки, в случае последнего всё это связывать клеем;
- Не сыскал популярности со всеми вытекающими. Десктопных приложений очень мало. Мобильные приложения тоже пишут больше на родных, а то и Web-костылях. Единственное широкое распространение: KDE Plasma 5, Sailfish и ныне покойные Ubuntu Touch и Unity 8;
- Куча проблем из-за аппаратного ускорения отрисовки. На офисной Win-машинке со слабым GPU и отсутствием поддержки OpenGL 2.0 придётся использовать жуткие костыли в виде ANGLE, иначе просто ничего не будет запускаться. С ноутбуками и встройками от Intel/AMD тоже всё не очень гладко и куча проблем;
- Медленно, жрёт ресурсы CPU и RAM. JavaScript-интерпретатор со всеми вытекающими. Тянет много тяжёлых либ, есть требования от GPU;
- В популярных IDE слабая поддержка QML или её там нет вообще.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от EXL

Надеюсь, не Шлее.

А чем он плох?

склеивание соплями QtQuick-кода с C++.

Я в основном именно связки QML и C++ видел. Но писали что связать несложно.

The Qt Company может вскоре отказаться от развития и поддержки QtWidgets (вспоминаем QtScript, QtWebkit и пр.);

Ну, QtWebkit всё ещё жив, да и не думаю что так резко возьмут и выкинут. Всё же технология куда более масштабная.

Из-за MOC и прочих надкомпиляторов большие QtWidgets-проекты компилируются достаточно долго;

До лампочки, и сутки ждать смогу.

На Android и iOS выглядят как говно и работают точно так же.

Аналогично, мобилки не нужны (мне).

QML/QtQuick

Поддержки родных системных контролов по сути нет. То что есть — ужас и срам. Тулкит хоть и поддерживает кое-какие HIG'и (Material, Simple и др.), но является инородным абсолютно везде;

Не думаю что это такая большая проблема. Должно же быть разнообразие во внешнем виде ПО.

Куча проблем из-за аппаратного ускорения отрисовки. На офисной Win-машинке со слабым GPU и отсутствием поддержки OpenGL 2.0 придётся использовать жуткие костыли в виде ANGLE, иначе просто ничего не будет запускаться. С ноутбуками и встройками от Intel/AMD тоже всё не очень гладко и куча проблем

А вот это уже реально минус. В общем, теперь я ещё больше запутался в выборе...

Sunderland93 ★★★★★
() автор топика
Ответ на: комментарий от Sunderland93

А вот это уже реально минус.

Оно ещё и в виртуалке не работает нормально.

RazrFalcon ★★★★★
()
Ответ на: комментарий от Sunderland93

А чем он плох?

1. Это больше обзорная книга. То есть полистать-посмотреть что представляет из себя Qt, какие там есть виджеты и модули — ОК. Что-то учить по этой книге как-то, эм... ну как по рекламному буклету.

2. Шлее упорный пользователь MS Windows и мышлением из той же среды. А это значит, что во всех кусках кода и примерах в книге: https://ru.wikipedia.org/wiki/Венгерская_нотация

3. Его последняя книга про Qt 5.3 — откровенная халтура. По сути это Ctrl+C и Ctrl+V из прошлой части и выкидывание того, что выкинули сами Qt Developers.

Короче, я за книгу от одного из разработчиков Qt: https://www.ozon.ru/context/detail/id/4005805/ (в инете куча копий)

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

До лампочки, и сутки ждать смогу.

Это к тому, что если ты захочешь «подогнать» что-то в сложном QtWidgets-приложении и это что-то нужно будет непременно поменять в заголовочном файле, с которым работает несколько классов, то при итерациях «подгонки», тебе нужно будет ждать по несколько десятков секунд, чтобы увидеть результат. В QtQuick такой проблемы тупо нет.

Ну, QtWebkit всё ещё жив, да и не думаю что так резко возьмут и выкинут.

Вот как раз его очень резко взяли и выкинули. А вместе с этим сломали Qt Assistant, сломали разметку документации в Qt Creator, так как перешли с QtWebkit на QTextBrowser + Simple Html. И всем пофиг, что показательно. Это именно если смотреть в Qt-экосистему. Куча софта раньше юзала этот Assistant для внутренней документации. Теперь она с трудом и скрипом будет либо мигрировать на 5.6 / 5.7, либо останется на < 5.6

EXL ★★★★★
()
Ответ на: комментарий от robus

а зачем читать «xml-ским АДОМ, генерируемым Qt Designer-ом» ?

next_time ★★★★★
()
Ответ на: комментарий от fluorite

Я вообще не знаю никаких новых редакторов, IDE или мессенджеров, если честно.

Не читаешь новости? Они растут как грибы после дождя. Всякие Wire, Ring и пр.

Вот кстати. Почему Skype, который был ранее завязан на Qt 4, перешёл внезапно не на Qt 5 и QtQuick/QML, а на... Electon.

А что значит — не похоже?

Оно свёрстано по мобильным гайдлайнам. Заголовок с тремя полосками «меню», крупные кнопки, анимированное переключение контекста и пр.

EXL ★★★★★
()
Ответ на: комментарий от EXL

Это больше обзорная книга. То есть полистать-посмотреть что представляет из себя Qt, какие там есть виджеты и модули — ОК.

Да и это сойдёт для начала.

Шлее упорный пользователь MS Windows и мышлением из той же среды.

Это я заметил. Потому и рассматриваю несколько разных «литератур», включая официальную документацию. Осложняет дело моё не слишком великое знание англицкого.

Это к тому, что если ты захочешь «подогнать» что-то в сложном QtWidgets-приложении и это что-то нужно будет непременно поменять в заголовочном файле, с которым работает несколько классов, то при итерациях «подгонки», тебе нужно будет ждать по несколько десятков секунд, чтобы увидеть результат. В QtQuick такой проблемы тупо нет.

А, ты об этом. Ну да, неудобно.

Вот как раз его очень резко взяли и выкинули. А вместе с этим сломали Qt Assistant, сломали разметку документации в Qt Creator, так как перешли с QtWebkit на QTextBrowser + Simple Html. И всем пофиг, что показательно. Это именно если смотреть в Qt-экосистему. Куча софта раньше юзала этот Assistant для внутренней документации. Теперь она с трудом и скрипом будет либо мигрировать на 5.6 / 5.7, либо останется на < 5.6

Сурово. Надеюсь всё же виджетов не коснётся в ближайшие годы

Sunderland93 ★★★★★
() автор топика
Последнее исправление: Sunderland93 (всего исправлений: 1)
Ответ на: комментарий от EXL

Не слежу за мессенджерами, меня даже вконтакте как средство доставки сообщений устраивает. В браузере. :)

Про скайп — это к микрософту, могли вообще линукс перестать поддерживать, переписав на чём-то маздаеспецифичном. Из-за мака не стали, наверное.

Что до мобильных гайдлайнов — как дизайнер нарисовал, так и сделали (а на qml pixel-perfect делать несравненно проще, чем на виджетах). Но вообще это тенденция — единообразный стиль приложений для всех платформ, включая веб.

fluorite ★★★★★
()
Ответ на: комментарий от Sunderland93

Виджеты KDAB поддерживают, куда б они делись. Про вебкит -- это да, резковато вышло. Хорошо, что есть коммьюнити. Спасибо annulen, что поддерживаешь webkit новых версий.

fluorite ★★★★★
()
Ответ на: комментарий от Sunderland93

Да и это сойдёт для начала.

Потому и рассматриваю несколько разных «литератур»

Вот для начала я как раз и советую Жасмина/Бланшета по QtWidgets. Причём не обязательно всю книгу, а только пару первых глав оттуда на вечерок.

А по QtQuick я могу посоветовать это: http://qmlbook.github.io/

Сурово. Надеюсь всё же виджетов не коснётся в ближайшие годы

Да, именно так. Теперь в Qt Creator и Qt Assistant всё перенесено с QtWebKit на QTextBrowser, а по дороге отвалилось:

  • Разметка;
  • Шрифты;
  • Подсветка синтаксиса;
  • Стили;
  • Переходы.

Qt Assistant здорового человека, Qt 5.5.1, QtWebKit: http://esxi.z-lab.me:666/~exl_lab/screens/qt_assistant_norm.jpg
Qt Assistant курильщика, Qt 5.7.0+, QTextBrowser: http://esxi.z-lab.me:666/~exl_lab/screens/qt_assistant_not_norm.jpg

EXL ★★★★★
()
Ответ на: комментарий от fluorite

Виджеты KDAB поддерживают, куда б они делись.

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

Спасибо annulen, что поддерживаешь webkit новых версий.

Пожалуйста :)

annulen ★★★★★
()
Ответ на: комментарий от Sunderland93

Примерно такой GUI мечтаю запилить для одного игрового эмулятора. А вот такой наверно проще будет на QML написать?

Тут интерфейс совсем простой, на QML можно оба накидать за пару часов.

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

CrossFire ★★★★★
()
Последнее исправление: CrossFire (всего исправлений: 1)

Освой и то, и другое.

Я вообще, в своём проекте хочу не «или», а вместе". Всё, что не зависит от гуя, выносится отдельно, гуй для десктопа пишется на виджетах, для мобилок - на QML. Собственно, ядро проекта и гуй на виджетах потихоньку развиваются, QML буду дёргать, когда доведу десктопную версию до определённого уровня приличия.

Помимо всего прочего, виджеты позволяют поддерживать сборку под Qt4, которая всё ещё привлекательна для некоторых платформ ввиду своей стабильности и неприхотливости. QML в поздних Qt4 уже был, но насколько я понимаю (поправьте, если ошибаюсь), там он был в зачаточном виде, и с тех пор его поломали куда сильнее, чем виджеты.

hobbit ★★★★★
()
Ответ на: комментарий от fluorite

Про скайп — это к микрософту, могли вообще линукс перестать поддерживать, переписав на чём-то маздаеспецифичном. Из-за мака не стали, наверное.

Скорее, из-за антимонопольного иска со стороны Cisco, когда скайп покупали. MS отбрыкалась, в т.ч., обещанием, что поддержка будет сохранена под все платформы.

hobbit ★★★★★
()

Ну залезь в код того же телеграма - написан на голых виджетах, как работает хер проссышь. Следуй гайдам с qt.io (http://doc.qt.io/qt-5/qtquick-performance.html) и будет тебе счастье. В пределе на виджетах можно сделать гораздо шустрее, но код там будет не фонтан.

ya-betmen ★★★★★
()
Последнее исправление: ya-betmen (всего исправлений: 1)
Ответ на: комментарий от hobbit

QML в поздних Qt4 уже был, но насколько я понимаю (поправьте, если ошибаюсь), там он был в зачаточном виде, и с тех пор его поломали куда сильнее, чем виджеты.

Там много чего перепелили, из самого важного - композитинг и жс вм.

ya-betmen ★★★★★
()
Ответ на: комментарий от ya-betmen

Ну залезь в код того же телеграма - написан на голых виджетах

Что-то он выглядит как QML, они его имитируют на виджетах?

leonid
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.