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

Типа простота и удобство.

Удобство верстки и отделение представления от остальной логики.

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

Удобно писать интерфейсы. Но есть куча подводных камней, да и производительность в сравнении с QtWidgets оставляет желать лучшего.

В чем именно удобство выражается? 1. Я могу вручную создать объект (пусть QPushButton) 2. Я могу в дизайнере перетащить

Вот чем именно QML проще? В чем конкретно это выражается?

В чем именно удобство выражается?

В декларативном подходе.

Попробуй пару примеров потыкать, сам поймёшь.

https://qmlbook.github.io/en/ch04/index.html

Для мобилок. На десктопе ему не место.

Главное удобство - в проперти биндингах. Очень корявый аналог есть в javafx - там оно в 10 раз многословнее, а тут просто магия и работает. Qml позволяет писать на порядки меньше кода (и оно куда читабельнее).

Но все же оно не идеально. Идеал - если бы qml был бы компайлтаймовым. Может в будущем до того и дойдут.

Чо это? Я не заметил разницы в производительности для простых приложений, а о декларативном интерфейсе я мечтаю со времен программирования с ncurses.

Он после первого запуска вполне себе байткодовый.

производительность в сравнении с QtWidgets оставляет желать лучшего

А што, QtWidgets используют полную аппаратную отрисовку?

На хеллоу ворлде не ощутишь

А причём здесь отрисовка к вебне внутри QtQuick/QML?

Qt Quick сложно использовать для написания классических интерфейсов, т.е. он пока не может быть полноценной заменой Qt Widgets. Qt Quick Controls 2 в последних версиях движется в этом направлении, но до реализации полной функциональности еще очень далеко.

Также раздражает завязанность на JS. Конечно, все вещи, для которых используется JS можно сделать и на C++, но придется писать в 10 раз больше ненужной лапши, что нивелирует все плюсы QML (я говорю именно про простые вещи, например функция на несколько строк, вызываемая при нажатии кнопки. Основная логика пишется на С++). А JS добавляет собственные проблемы.

При чём тут вебня?

А я заметил.

https://wiki.qt.io/V4
http://wiki.qt.io/Qt-contributors-summit-2013-QML-engine

У меня вся Плазма и половина KDE Apps использует QML. При чём тут вебня?

Ты не один, брат. Этого никто не понимает.

К вебне это отношения не имеет. QML не использует DOM, CSS или HTML. JS там используется для связывания QML-объектов между собой (которые в свою очередь являются C++-объектами).

При JavaScript'е.

О, давай бенчмарки. Мне правда интересно.

Для JavaScript в его любой ипостаси скорость исполнения гораздо ниже, чем у C++.

Давай сорцы бенчей.

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

И что, что джаваскрипт? Если я на похапэ напишу системную утилиту, это тоже вебня будет? Чё за херню ты несёшь?

Тем более, в QML от джаваскрипта какие-то останки используются. Иксперт херов.

Пажжи, ты же говоришь, что заметил. Как мерял? И на чем?

ты можешь не использовать JS в QML.

QML Engine это и есть V4 JavaScript Engine. Любое выражение в QML у тебя обрабатывается как JavaScript-выражение, независимо от того, используешь ты внешние JavaScript-файлы или нет.

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

И что, что джаваскрипт?

Зачем нужен QML в Qt? (комментарий)

Иксперт херов.

Потуши свой жопный огонь, фрактальчик.

Ща ты такой бенчи в студию

Да, я обо всем об этом: http://blog.qt.io/blog/2013/04/15/evolution-of-the-qml-engine-part-1/

для всяких простеньких программок, где три окошка и пять диалогов

Вот ты и пришёл к понимаю того, для чего нужен QtQuick/QML.

Ща ты такой нахер из треда.

Ну да. Всякие чатики, плееры и вьюверы картинок. Милое дело.

Обосралась лалка? Ну это не кукарекать без пруфов

Ты идиот? Идиот.

Ну да. Всякие чатики, плееры и вьюверы картинок. Милое дело.

Ну как Electron или даже лучше.

Найс тебя рвёт. Ну нехер кукарекать.

Предположим, у тебя есть кнопка. При ее нажатии вызывается функция на Haskell ( или C++, неважно). Но тебе нужно, чтобы в зависимости от состояния других UI-элементов вызывалась другая функция (или поставлялись другие аргументы, и т.п.). И тут уже вместо простого вызова функции ты в обработчике onClicked пишешь логику на JavaScript, потому что это самый простой способ доступа к других QML-объектам.

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

Давай, смайлики запости ещё. Выбиваешься из стиля.

Когда от тебя пруфы в виде бенчей ждать? Подозреваю, что никогда, как обычно.

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

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

Типа:

    frame frmTwoButtons {
        vboxlayout layButtons {
            color: "#7c7c7c"
            pushbutton btnStart {
                text: "Start Job"
            }
            pushbutton btnStop {
                text: "Stop Job"
            }
        }
    }

При компиляции превращаем frame в QFrame и др. Думаю, что и тот же property binding можно было бы прикрутить генерацией дополнительного кода, ну примерно как с moc (хотя могу ошибаться).

Можно пример такой ситуации?

У меня кеды. Тут полно qml. Ну и демки тыкал. Лагает что смерть. Никакие бенчи мне не нужны.

Дело не в байткоде, а в куче ошибок которые отловятся только в рантайме, вплоть до опечаток. А я хотел что то вроде Vibe.d с его diet-шаблонами, все в компайл-тайме.

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

Это неприятно, но в целом решается тестированием, которое все равно придется делать.

А ты уверен, что дело в qml? Я помню, что кеды у меня и до qml тормозили.

Тестирование должно тестировать логику, а не банальные опечатки и нерабочий код. То, что может вскрыться на этапе компиляции - должно там и вскрываться.

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