QML, нужно ли?

[ViTech]

Есть ли смысл переделать интерфейс в QML и насколько это сложно?
Критична стабильность приложения.

Смотря какие цели преследуются. Сделать красиво? Запуск на мобильных устройствах? Если нужна простота и стабильность, то лучше оставить как есть .

OKTA, хочется проработать вопрос переноса GUI в QML. Насколько это реально - т.е. прикрутить к бизнес-логике QML и 2 элемента на opengl (Виджеты 2d и 3d тяжелые и красивые в QML не засунуть). При этом структура должна быть красивой и без костылей.

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

По поводу виджетов на QML, похоже ещё не так хорошо, как хотелось бы. Что есть на текущий момент, можно посмотреть в модулях Quick *. Нужно приготовиться к тому, что многое придётся делать своими руками.

Избежать тормозов может помочь знание внутренней кухни рендеринга QML, например Qt Quick Scene Graph Renderer.

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

[deMax]

А есть аналог QML чтоб без java и интерпретатора. Я вот задумываюсь взять QML или что то похожее и самому пропарсить.

Смотря какие цели преследуются. Сделать красиво? Запуск на мобильных устройствах? Если нужна простота и стабильность, то лучше оставить как есть .

Мобильные устройства пока не нужны.

Одно и то же можно сделать разными способами и тормозить/летать будет соответственно

Ага только как не изголяйся, а java без суперкомпьютера все равно тормозить будет(для средних задач).

[ViTech]

Ну там не java, а javascript, что несколько разные вещи. Не знаю, насколько там много интерпретируется, но из дерева элементов Item qml-файла создаётся дерево QQuickItem в С++, которые QObject со всеми сигналами, слотами и прочими финтифлюшками. Основная работа идёт с деревом QQuickItem. На эту тему можно посмотреть классы QQmlEngine и QQmlComponent. Так что так уж сильно тормозить не должно. Зависеть будет от количества элементов, организации их взаимодействия и пониманием тонкостей работы QML.

Самому парсить QML смысла не вижу. С таким же успехом можно парсить json, например, что легче будет. Фишка QML в том, что описание структуры элементов сочетается с возможностью определения действий над ними. Если в qml-файле определить только структуру элементов, без взаимодействия на javascript, то после загрузки этого файла стандартным образом можно обращаться к этой структуре из С++ без всяких интерпретаторов. Но некоторые действия лучше на javascript в qml-файле определить, чем в С++ с ними корячиться .

[RSATom]

В последних версиях Qt QML при реализации своих компонент есть возможность опуститься непосредственно до OpenGL ES 2.0. Это конечно не совсем тривиально, но возможно. Тем самым можно совместить удобство QML с возможность использования OpenGL по полной программе, без оглядки на возможности существующих Qt Quick элементов. Я делал это однажды (но задача была относительно простой), если интересно могу дать ссылку на исходники (github)

[deMax]

Да интересно, самое главное вопрос производительности.

[RSATom]

https://github.com/RSATom/QmlVlc

то что непосредственно связано с низкоуровневой отрисовкой:
https://github.com/RSATom/QmlVlc/blob/master/QmlVlcVideoSurface.h
https://github.com/RSATom/QmlVlc/blob/master/QmlVlcVideoSurface.cpp
https://github.com/RSATom/QmlVlc/blob/master/SGVlcVideoNode.h
https://github.com/RSATom/QmlVlc/blob/master/SGVlcVideoNode.cpp

здесь QmlVlcVideoSurface - это интерфейс для использования в Qml, SGVlcVideoNode - низкоуровневый отрисовщик.


можно посмотреть как это все работает "в живую":
https://sourceforge.net/projects/WebChimera - плагин для браузера базирующийся на вышеупомянутой библиотеке.
http://rsatom.github.io/WebChimera - несколько демок для него.

ну и в десктоп варианте можно собрать через это:
https://github.com/RSATom/QmlVlcDemo

[Отражение луны]

Избежать тормозов может помочь знание внутренней кухни рендеринга QML, например Qt Quick Scene Graph Renderer.

В моём проекте на qml/js перенесена тонна логики, используются шейдер эффекты, динамическая загрузка компонентов и прочие плюшки. Могу с уверенностью сказать, что qtquick не тормозит почти ни при каких условиях. Но если на машине проблемы с поддержкой OpenGL - будет тяжко. (я кэп).

(соединение с данными напрямую, биз сигналов и слотов)

В qml Вы можете использовать ссылки и вызывать функции напрямую, минуя систему сигналов.

ибо QML-вские view сортировку не поддерживают.

С чего бы view поддерживать сортировку, если она должна выполняться в моделях?

[Alex Custov]

С чего бы view поддерживать сортировку, если она должна выполняться в моделях?

Почему должна?

[Отражение луны]

Почему должна?

Архитектурно - модели определяют сами данные и их порядок, а view их только отображают в нужном представлении, используя делегаты. Почему именно так - вопрос к разработчикам qt, но я с их решением вполне согласен.

[Alex Custov]

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

Почему сортировка не является одним из методов отображения данных? Как раз является. Просто разработчики на данный момент заставляют нас сортировать самим через промежуточную модель.

[Отражение луны]

Почему сортировка не является одним из методов отображения данных? Как раз является. Просто разработчики на данный момент заставляют нас сортировать самим через промежуточную модель.

Зачем тебе промежуточная модель, если ты можешь реализовать сортировку в изначальной? И зачем тебе сортировка на этапе view, если реализация сортировки на этапе model гарантирует, что любой view будет отображать элементы в этой сортировке? (А иначе же не факт, что view будет поддерживать нужную сортировку).
Тут даже обсуждать нечего, предлагаю закончить оффтоп, а Вам пойти и составить багрепорт, если читаете свою позицию верной.

[Alex Custov]

И зачем тебе сортировка на этапе view, если реализация сортировки на этапе model гарантирует, что любой view будет отображать элементы в этой сортировке?

Мне это не нужно и даже вредно. Думаю, что принудительно сортировать исходную модель без промежуточной - вообще bad design. Это исключает несколько view для одной и той же модели, которые сортируют по-разному (как есть у меня).

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

Возможно.

[Отражение луны]

Мне это не нужно и даже вредно. Думаю, что принудительно сортировать исходную модель без промежуточной - вообще bad design. Это исключает несколько view для одной и той же модели, которые сортируют по-разному (как есть у меня).

Исключает - определенно, но плохой ли это дизайн - не думаю. В большинстве случаев модель не должна являться изначальным источником/контейнером данных, её задача - представить данные в уже готовом для отображения виде. Например, если Вы используете ListModel для формирования списка, потом еще одну ListModel для фильтрации/сортировки первого, то Вам стоит вместо первого ListModel использовать обычный яваскрипт массив.
При такой концепции, кончено, на каждый view нужно создавать по экземпляру модели. Фильтрация при этом реализуется в классе модели, но параметры фильтрации могут задаваться для каждого экземпляра свои.

[Alex Custov]

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

В терминах MVC модель - это как раз склад данных. Их отображением занимается view. Об отображении модель ничего не знает, и поэтому не может в общем виде как-то подготовить данные для него. Можно конечно на это всё забить, и сортировать модель напрямую, но это уже будет не MVC, а что-то другое.

Например, если Вы используете ListModel для формирования списка, потом еще одну ListModel для фильтрации/сортировки первого

А зачем тут второй ListModel? Я забыл ещё, что ещё одна проблема в том, что в QML нет сортирующей модели типа QSortFilterProxyModel, и поэтому по-правильному модель придётся переместить в C++, и использовать QSortFilterProxyModel. Именно это я имел ввиду, когда говорил о промежуточной модели (у меня модель и так в С++, поэтому для меня это получилось очевидно).

[ViTech]

Избежать тормозов может помочь знание внутренней кухни рендеринга QML, например Qt Quick Scene Graph Renderer.

В моём проекте на qml/js перенесена тонна логики, используются шейдер эффекты, динамическая загрузка компонентов и прочие плюшки. Могу с уверенностью сказать, что qtquick не тормозит почти ни при каких условиях. Но если на машине проблемы с поддержкой OpenGL - будет тяжко. (я кэп).

В моём проекте, например, ползают муравьи. Над каждым из них прямоугольник с текстовой информацией, которая может меняться несколько раз в секунду. Прямоугольники с текстом полупрозрачные. Муравьёв пускай будет тысяч пять. При таких условиях QtQuick не будет тормозить? Проблем с поддержкой OpenGL на машине нет.

И да, я хочу на экране видеть всех муравьёв одновременно. И прямоугольники с актуальной информацией над каждым. Ибо каждый муравьишка дорог моему сердцу, и я не хочу никого обделять своим вниманием .