Развертывание QML приложения
Всем доброго дня!
Использую windeployqt --qmldir для своих приложений, всё собирается, переносится на другие ПК, всё отлично. Однако при этом собирается куча базовых Qt исходников .qml файлов (в папках приложения ..\QtQuick\Controls\ ..\QtQuick\Controls.2\ ..\QtGraphicalEffects и т.д.). Этот факт делает приложение набитым файлами "для разработчика". При поиске решения "как не таскать с собой кучу базовых .qml файлов" я выяснил что разгадка где-то в плагинах QuickControls, но как это использовать я не смог разобраться.
В своём приложении все пользовательские .qml файлы я подгружаю в ресурсы, в .pro файле ссылки на них в DISTFILES не добавляю.
<RCC> <qresource prefix="/"> <file>main.qml</file> .... </qresource> </RCC>
Этот вопрос обсуждался
тут
, где я и подчерпнул что надо копать в сторону плагинов, но, увы, не разобрался.
Прошу помочь в данном вопросе, возможно, многим будет интересно узнать, как же лаконично собрать своё QML приложение.
Рекомендуем хостинг TIMEWEB
Стабильный хостинг, на котором располагается социальная сеть EVILEG. Для проектов на Django рекомендуем VDS хостинг.Ол саған ұнайды ма? Әлеуметтік желілерде бөлісіңіз!
Пікірлер
- Ora Iro
- Жел. 24, 2024, 6:38 Т.Ж.
C++ - Тест 001. Первая программа и типы данных
- Нәтиже:40ұпай,
- Бағалау ұпайлары-8
- Akiv Doros
- Қар. 11, 2024, 2:58 Т.Қ.
C++ - Тест 004. Указатели, Массивы и Циклы
- Нәтиже:50ұпай,
- Бағалау ұпайлары-4
- molni99
- Қаз. 26, 2024, 1:37 Т.Ж.
C++ - Тест 004. Указатели, Массивы и Циклы
- Нәтиже:80ұпай,
- Бағалау ұпайлары4
добавь в pro
CONFIG += qtquickcompiler
у меня windeployqt --qmldir тоже собирает 100500 файлов. И сдеди них немало *.qml. Но среди них только qml из состава QML (например QtGraphicalEffects). Но ни каких main.qml, и я тоже все свои исходники я убрал в ресурсы.
ps не сразу понял суть вопроса. Нужно избавиться от базовых QtGraphicalEffects? А зачем? Это не "как вы выразились" файлы для разработчика, это файлы для работы программы.
Если сбор 100500 файлов это обычная практика, и заморачиваться не стоит, пусть так. При windeployqt проект полон к примеру файлов стилей Fusion, Imagine, Material, Universal. Вот для работы программы, которая использует один стиль, зачем все таскать. Да и .qml при удалении оставляют программу рабочей (деплой уже подготовил .qmlc). Назвал я эти файлы "для разработчика" потому что они часть исходников смого Qt. Отсюда и возник вопрос, готовая собранная программа обязана содержать такое количество файлов-исходников, которые в таком виде(.qml) пользователю ПО вообще не нужны. (достаточно бы и .qmlc). (мы же не предоставляем, например, прошивки пользователю в .с файле, который он может открыть, для пользователя достаточно уже готового .hex или .bin).
Но повторюсь, я услышал от Вас что данная практика считается нормальной, и при динамической сборке много чего тут не придумаешь.
не совсем удачное сравнение QML с СИ. QML - это интопретируемый язык, СИ - это компилируемый. Сравните QML с JS или питоном. Конечная программа - это есть исходный код (хотя есть способы из питона получить пуре .ехе, например gimp)
У нас скаду прогеры писали на Qt, а GUI на qml. Конечный продукт был exe+dll+кучаQml. Причем .qml не только базовые, но и все самописные исходные (аля myFile.qml). Весь гуй шол на qml и исходниками лежал рядом с ехе. Если исправлялась ошибка в гуях, то у конечного пользователя обновлялся только соответствующий *.qml файл.
Из-за "интерпритации" раньше гуи на qml работал гораздо тормознутее, чем на Qt. Но сейчас современные ПК шустрые и этой разници особо не видно. Также добавили qtquickcompiler. А вот если писать ПО для ембеддед со слабым GPU, то иной раз эта интерпритация подтормаживает. Например при смене раскладки виртуальной клавиатуры rus-en en-rus, такое чувство, что идет компиляция новой клавиатуры и только после прорисовка. Конечно хотелось бы чтобы вся компиляция QML произошла на этапе сборки ПО и при выполнении был только машинный нативный код, чтоб было уже две готовых клавиатуры и было-бы быстрое переключение.
Полностью согласен, что пример не удачный, но я так как раз попытался выразить то, что вы далее описали с примером со скадой, часть .dll и часть .qml с интерпритацией.
И в Вашем ответе я увидел что меня и интересовало - нету (и их не надо искать) способов перевода всего .qml приложения в машинный код на этапе сборки ПО. Сапасибо.