LINUX.ORG.RU

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

 ,


0

3

Добрый день, все никак не пойму. Как профит от этого QML, что в нем можно сделать такого, что нельзя сделать в Qt. Интерфейсы, сигналы, слоты. Может я что-то очень важное не понимаю? Подскажите пожалуйста, не знаю, изучать мне QML или нет, может действительно там что-то скрыто такое?


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

das_tier ★★★★★ ()

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

fman2 ()

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

Deleted ()

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

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

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

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

da17 ()

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

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

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

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

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

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

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

Deleted ()
Ответ на: комментарий от kirk_johnson

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

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

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

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

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

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

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

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

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

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

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

Deleted ()
Ответ на: комментарий от kirk_johnson

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Типа:

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

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

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

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

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

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

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

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

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

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

kirk_johnson ★☆ ()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.