Зачем нужен QML в Qt?

Нечто подобное сейчас пилят KDAB'овцы: https://www.kdab.com/declarative-widgets/

Почему так не было сделано изначально — загадка. Возможно Nokia хотела снизить порог вхождения в разработку мобильных приложений, разбавив C++ с помощью JavaScript'а.

кдешники как раз пилят попытку совместить qml с обычными виджетами

KDAB'овцы. https://github.com/KDAB/DeclarativeWidgets

Или у KDE'шников имеется собственное решение?

Пример из моего кода:

onClicked: {
        if (selectionPanel.openPanel) {
            selectionModel.select(model.index)
        } else {
            pageStack.push("TorrentPropertiesPage.qml", {"torrentHash": torrent.hashString,
                                                         "torrent": torrent})
        }
}

Не понял, что такое панель мультивыбора.

Нет. Это я в виду и имел - я почему то думал что KDAB связан с кедами - по первой букве же. Ну и новость эту я на planetkde прочитал.

Это не избавляет от JS. Там используется тот же QML, только вместо виджетов Qt Quick и Qt Quick Controls используются виджеты Qt Widgets. Связи между ними все так же пишутся на JS.

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

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

Кдешники пилят стиль для Qt Quick Controls 2, который использует QStyle для отрисовки и мимикрирует под Qt Widgets.

Виджеты не тормозят.

Неважно, десктоп или нет. Если программа достаточно сложная, то при разработке появляется море ситуаций, когда нужно при определенном действии изменить состояние других QML-объектов, и это сложно сделать с помощью property bindings или states. В таком случае приходится использовать логику на JS. Загляни хотя бы в код той же плазмы - практически в каждом QML-файле есть логика на JS, где-то в несколько строк, где-то больше. От этого никуда не деться.

Я понимаю, что сейчас это не избавит от JavaScript. Но это хотя бы даст нормальную связку существующих технологий.

Как было сказано выше, когда ещё QML только-только зарождался, они могли сделать этот DSL с помощью кодогенерации на стороне moc или похожей утилиты и весь QML был бы по типу Vala с минимальным оверхедом.

Сейчас же в стране QtQuick царит какой-то беспорядок: одни системные GUI-контролы чего стоят. Вместо того, чтобы допилить, их просто выбрасывают и пилят заново новые. Уже третий или четвёртый набор так.

Виджеты не тормозят.

А логика тормозит. Особенно, если интерфейс с ней в одном потоке. Это я тебе как пользователь mutt говорю.

Если достаточно сложная, то да. Но если там действительно несколько строк, то и насрать.

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

И кто мешает вынести логику?

думал что KDAB связан с кедами

KDAB сильно связан с Qt, т.к. это серьёзная компания у которой большая часть бизнеса зависит от этого фреймворка.

http://esxi.z-lab.me:666/~exl_lab/pics/kdab_qt_rimac1.jpg
http://esxi.z-lab.me:666/~exl_lab/pics/kdab_qt_rimac2.png

Кажется они самые активные коммитеры в Qt, чуть ли не опережают саму The Qt Company. Ну и конечно они выступают на всяких Qt/KDE тусовках от лица своей компании. Но называть их KDE'шниками вряд ли правильно.

Ещё KDAB замутили крутое средство интроспекции Qt- и QML-приложений — GammaRay, много раз выручал.

P.S. А planetkde просто ретранслирует всю около Qt-движуху (точнее репостит с planetqt).

И кто мешает вынести логику?

Это уже о другом разговор. Мы с тобой говорили о том, что qml тормозит. Однако мы только что выяснили, что дело может быть не только в нем.

Как это сделать без использования JS?

http://doc.qt.io/qt-5/qtqml-cppintegration-interactqmlfromcpp.html#connecting...

И я что-то не уверен, что уйдя в C++, на том же QML-уровне это будет «без использования JS».

Это-то понятно. Проблема в том, что в обработчике onClicked мне нужен доступ к другим QML-объектам. Если я хочу чтобы он был полностью на C++, мне придётся писать кучу лапши, т.к. доступ к QML- объектам из C++ (а не наоборот) реализован очень неудобно, именно потому, что в QML такие ситуации by design принято разруливать с помощью JS.

Однако мы только что выяснили, что дело может быть не только в нем.

Хватит разговаривать с голосами в голове. Тормозит QML. ТЧК.

Хватит разговаривать с голосами в голове. Тормозит QML. ТЧК.

Пруфы, Билли, нам нужны пруфы!

Если из QML кода постоянно выносить логику в кресты, то от QML остаётся лишь одна декларативщина. Но если нам нужна только декларативщина, то зачем нам тяжёлый QML, который в своём нутре использует V4 JavaScript Engine? А раз нам такое не нужно, то почему QML получился таким, а не простым декларативным DSL, который бы отдельная утилита разворачивала в компактный C++-класс со всеми заданными свойствами и условиями, как это делает тот же uic только в упрощённой форме и GUI only? QML ведь как ни крути, всё равно строится поверх C++/Qt API в своих модулях.

Проблема в том, то QML позиционируется разработчиками Qt как инструмент для написания любых интерфейсов, т.е. любой сложности. А в сложных интерфейсах (да дело даже не в сложности самого интерфейса, а в логике, т.е. действиях, которые происходят при взаимодействии с ним) без логики на JS не обойтись, потому что UI-элементы тоже должны взаимодействовать между собой, и часто это должно описываться достаточно сложной логикой, для которой простых property bindings и states недостаточно. Для этого в QML и сделали встроенную поддержку JS. Т.е. утверждение, что в QML интерфейс полностью отделен от логики - миф. На деле он отделен только от бекэндовой логики, которая пишется на C++ или другом ЯП. Логика же самого интерфейса пишется на JS.

Логика же самого интерфейса пишется на JS.

Ну все-таки «мы тут парой функций накостыляли» и «интерфейс пишется на JS» это две большие разницы.

Я не говорю, что интерфейс пишется на JS. Логика взаимодейтсвия между UI-элементами пишется на JS.

Я не говорю, что интерфейс пишется на JS. Логика взаимодейтсвия между UI-элементами пишется на JS.

Окей, да, согласен.

Ну все-таки «мы тут парой функций накостыляли»

А логика тормозит (c)

А если бы ничего не тормозило, то QtQuick/QML бы не находился в стадии вечного переписывания. Сначала его (ещё в Nokia) сделали на QSA и QtScript, потом в QML началась эпопея с переписыванием на V4, попутно заигрывая с V8. Сегодня к нему прикручивают это http://doc.qt.io/QtQuickCompiler/

При этом до сих пор нет стабильно поддерживаемых контроллов из коробки и все костыляют свои собственные. Сколько там всяких наборов было за один только Qt 5 было анонсировано?

Компилер у него давно. Просто в платной версии :)

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

А насчет тормозов - я такого не заметил (если все делать грамотно). Основные претензии у к QML у меня это JS (можно было бы использовать более строгий язык, хоть даже свой собственный) и непригодность Qt Quick для написания десктопных интерфейсов.

Ненужен.

Компилер у него давно. Просто в платной версии :)

На одном стуле JIT прогретый, на другом мы пришли к компиляции в С++ но с оверхедом...

А логика тормозит (c)

Алсо пару сигналов послать все-таки не то чтобы прямо «нагрузим GC по полной да ещё на IO заблочимся».

На одном стуле JIT прогретый, на другом мы пришли к компиляции в С++ но с оверхедом...

Не, компилер в байткод. Не в C++ :D

Я так и не понял, зачем оно теперь, когда qml при первом запуске кешируется тебе в ~/.cache. Видимо шоп поменьше мусорить.

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

Я считаю, что кодогенерация туда и просится. И язык можно было бы строгий сделать, посмотри на ту же Vala, которая что-то примерное делает. Это было бы логично, ведь весь этот QML всё равно просто абстракция поверх С++ API. Если QML-элементы превращаются в обычные C++-классы, то почему ниточка, которая их всех соединяет, является JavaScript'ом с оверхедом на динамическую типизацию и пр.?

разработчики QML хотели упростить написание интерфейсной логики ... а JS многим знаком

Согласен с этим. Другое объяснение найти тут сложно. Они именно погнались за теми, кому «JS знаком», так как я помню эти рекламные ролики ещё старой Nokia, где они рассказывали какая у них простая и замечательная технология QtQuick, что даже дизайнер-блодинка с перового мокапа овладеет всей магией. Вот только спустя столько времени, можно точно сказать, что с аудиторией они ошиблись и те, кому «JS знаком», ушли на Electron и его мобильные аналоги.

Т.е. интерфейс мы пишем на QML + JS, а бэкенд на C++.

Если было бы так гладко. Но в итоге человеку, пишущему на QML всё равно нужно знать С++, потому что рано или поздно с ним придётся столкнуться.

uic по сути решает другие задачи, нежели QML. Он позволяет поределить иерархию, расположение контролов относительно друг друга, их внешний вид и т.п. Но он не позволяет определить логику взаимодействия контролов друг с другом

Это ты рассуждаешь в контексте сегодняшней ситуации с QtWidgets (кстати uic позволяет прокидывать и кастомные классы, что весьма полезно). Но если представить улучшенный uic, который читает не XML'ку, а декларативный и строгий DSL с логикой и затем транслирует его в C++, оставляя ниточки для тех кто занимается backend'ом, то вырисовывается куда более стройная концепция QtQuick. Чёрт возьми, её зачатки уже и так есть, взять хотя бы названия слотов вида void on_ИМЯОБЪЕКТА_СИГНАЛ(), которые автоматически разрешаются без задания слота/сигнала.

непригодность Qt Quick для написания десктопных интерфейсов.

В чём именно это заключается? Вот если рассматривать сам язык QML, его синтаксис, то он очень удобен для написания интерфейсов любой сложности. Это если смотреть в отрыве от реализации.

Как это сделать без использования JS?

выкинуть неочевидный UI и сделать как у нормальных людей?

Это мобильный интерфейс

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

Не, компилер в байткод. Не в C++ :D

Хм. А тут пишут что в intermediate/untyped C++: https://habr.com/post/354972/#add1

Я так и не понял, зачем оно теперь, когда qml при первом запуске кешируется тебе в ~/.cache.

Затем наверное и сделали, потому что первый запуск aka «холодный старт» слишком долгим получается. Особенно на мобильных устройствах. Представь, пока там Qt развернётся в память, потом QML, потом загрузятся qml-файлы из ресурсов, скомпилируются в кеш и т. д. Когда я тыкал QtQuick на Android, время запуска в сравнении с любым приложением на родных Java API, удручало. Тут рапортуют о +30% к скорости запуска.

~/.cache. Видимо шоп поменьше мусорить.

Кстати в последних версиях оно кладёт файлы не в ~/.cache, а прямо рядом с сорцами мусорит всякими *.qmlc и *.jsc

Компилер у него давно. Просто в платной версии :)

З.Ы. оказывается устарел уже этот ынтерпрайзный компайлер. Я даже не успеваю отслеживать что там происходит на фронте Qt Quick, столько всего они постоянно запиливают и выкидывают.

Почему я назвал Qt Quick Compiler «старым» и вообще использовал прошедшее время? Потому что он прекращает своё существование как генератор C++ кода из QML/JS, и в Qt 5.11 он станет доступен во-первых, всем пользователям, а не только обладателям коммерческой лицензии, а во-вторых, его реализация будет существенно отличаться от текущей, и он больше не будет генерировать C++ код, а будет генерировать тот же байт-код, что и QML кэшинг.

Ээээ... ты можешь не использовать JS в QML. Я там только декларативку делал. Вся логика была на хачкеле :)

Ловите наркомана!

Кстати в последних версиях оно кладёт файлы не в ~/.cache, а прямо рядом с сорцами мусорит всякими *.qmlc и *.jsc

Что есть хорошо, ибо ты можешь это опакетить :)

На самом деле, тут есть довольно большая проблема, которую так и не обсудили — в интерпретаторе может быть дыра. Но это уже к вопросу убогости sandbox в лялехе.

Чтобы дизайнеры лепил красивый ui, а разработчики - логику.

что в нем можно сделать такого, что нельзя сделать в Qt

Можно легко пользоваться плюшками scene graph (а раньше эти api вообе были приватными для C++)

http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html

Вроде как позволяет проще делать графические интерфейсы, предоставляя простой синтаксис. Но по моему теперь все равно нужно хорошо знать и Qt/C++ и Qml, если весь проект делать в одиночку и, исходя из последнего, мне крайне не нравится.

Чтоб ты решал интересные задачи сопряжения этого с виджетами :)

В смысле «пилят»? При желании уже можно совмещать Не факт, что захочется, но можно :)

Вот такой вот интерфейс на QML быстрее будет сделать чем на виджетах? https://pastenow.ru/360CE

Сомневаюсь. В таком случае виджеты можно просто набросать на форму в Десигнере и вообще не париться — интерфейс простой и без странностей.

Ну ок, я чет вообще очень туплю, у меня по большей части все интерфейсы это кнопка «СТАРТ» для запуска системы и журнал работы. Я так понимаю, QML мне особенно не поможет.

Я хз насчет «быстрее» — это все сравнения яблок с апельсинами. Кто хорошо знает qml всяко сделает быстрее того, кто... плохо знает виджеты :) При хорошем знании виджетов все не так однозначно (меня буквально на днях больше волновало сопряжение кутей с прогой, которая не написана на Qt и никак от него не зависит, кроме предоставления кутевого интерфейса когда надо, в виде плугина к этой проге, — в т.ч. бесшовный старт SDL-ной графики с виджетами. Ну чо... не сказать что прям восторг, но решилось). Если кому-то qml больше подходит — почему бы и не. Заказчики софта редко соглашаются «взять и все переписать» — а интеграция давно отдельный бизнес.