Russian Qt Forum
Ноябрь 23, 2024, 11:31 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: 1 [2] 3   Вниз
  Печать  
Автор Тема: QML, нужно ли?  (Прочитано 22763 раз)
ViTech
Гипер активный житель
*****
Offline Offline

Сообщений: 858



Просмотр профиля
« Ответ #15 : Октябрь 16, 2014, 11:42 »

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

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

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

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

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

Пока сам не сделаешь...
deMax
Хакер
*****
Offline Offline

Сообщений: 600



Просмотр профиля
« Ответ #16 : Октябрь 16, 2014, 12:57 »

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

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

Одно и то же можно сделать разными способами и тормозить/летать будет соответственно
Ага только как не изголяйся, а java без суперкомпьютера все равно тормозить будет(для средних задач).
Записан
ViTech
Гипер активный житель
*****
Offline Offline

Сообщений: 858



Просмотр профиля
« Ответ #17 : Октябрь 16, 2014, 13:44 »

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

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

Пока сам не сделаешь...
RSATom
Гость
« Ответ #18 : Октябрь 17, 2014, 07:38 »

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

Сообщений: 600



Просмотр профиля
« Ответ #19 : Октябрь 21, 2014, 10:49 »

Да интересно, самое главное вопрос производительности.
Записан
RSATom
Гость
« Ответ #20 : Октябрь 21, 2014, 13:44 »

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
Записан
Отражение луны
Гость
« Ответ #21 : Октябрь 21, 2014, 19:58 »

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

ибо QML-вские view сортировку не поддерживают.
С чего бы view поддерживать сортировку, если она должна выполняться в моделях?
« Последнее редактирование: Октябрь 21, 2014, 20:09 от Отражение луны » Записан
Alex Custov
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2063


Просмотр профиля
« Ответ #22 : Октябрь 21, 2014, 20:31 »

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

Почему должна?
Записан
Отражение луны
Гость
« Ответ #23 : Октябрь 21, 2014, 20:53 »

Почему должна?
Архитектурно - модели определяют сами данные и их порядок, а view их только отображают в нужном представлении, используя делегаты. Почему именно так - вопрос к разработчикам qt, но я с их решением вполне согласен.
Записан
Alex Custov
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2063


Просмотр профиля
« Ответ #24 : Октябрь 21, 2014, 21:04 »

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

Почему сортировка не является одним из методов отображения данных? Как раз является. Просто разработчики на данный момент заставляют нас сортировать самим через промежуточную модель.
Записан
Отражение луны
Гость
« Ответ #25 : Октябрь 21, 2014, 21:35 »

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

Сообщений: 2063


Просмотр профиля
« Ответ #26 : Октябрь 21, 2014, 22:23 »

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

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

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

Возможно.
Записан
Отражение луны
Гость
« Ответ #27 : Октябрь 21, 2014, 23:08 »

Мне это не нужно и даже вредно. Думаю, что принудительно сортировать исходную модель без промежуточной - вообще bad design. Это исключает несколько view для одной и той же модели, которые сортируют по-разному (как есть у меня).
Исключает - определенно, но плохой ли это дизайн - не думаю. В большинстве случаев модель не должна являться изначальным источником/контейнером данных, её задача - представить данные в уже готовом для отображения виде. Например, если Вы используете ListModel для формирования списка, потом еще одну ListModel для фильтрации/сортировки первого, то Вам стоит вместо первого ListModel использовать обычный яваскрипт массив.
При такой концепции, кончено, на каждый view нужно создавать по экземпляру модели. Фильтрация при этом реализуется в классе модели, но параметры фильтрации могут задаваться для каждого экземпляра свои.
Записан
Alex Custov
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2063


Просмотр профиля
« Ответ #28 : Октябрь 21, 2014, 23:22 »

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

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

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

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

Сообщений: 858



Просмотр профиля
« Ответ #29 : Октябрь 22, 2014, 12:25 »

Избежать тормозов может помочь знание внутренней кухни рендеринга QML, например Qt Quick Scene Graph Renderer.
В моём проекте на qml/js перенесена тонна логики, используются шейдер эффекты, динамическая загрузка компонентов и прочие плюшки. Могу с уверенностью сказать, что qtquick не тормозит почти ни при каких условиях. Но если на машине проблемы с поддержкой OpenGL - будет тяжко. (я кэп).
В моём проекте, например, ползают муравьи. Над каждым из них прямоугольник с текстовой информацией, которая может меняться несколько раз в секунду. Прямоугольники с текстом полупрозрачные. Муравьёв пускай будет тысяч пять. При таких условиях QtQuick не будет тормозить? Проблем с поддержкой OpenGL на машине нет.

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

Пока сам не сделаешь...
Страниц: 1 [2] 3   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.058 секунд. Запросов: 23.