Последнее обновление:
May 16, 2020

Есть мысль... Жми, напиши!
Что имеем: Постов : 139 Авторов: 1 Категорий: 22

Qt 5.12 + Android с чего начать или Hello World

Потребовалось в очередной раз обновить Qt для кросскомпиляции под Андроид. В моём случае разработка идёт под Линукс, но с Виндой, думаю, особых проблем не будет.

Качаем Android SDK, для этого нужно скачать SDKManager. (На странице ищем «Command line tools only»), пока что не распаковываем.

Рабочим каталогом у меня будет «~/Projects/ANDROID», все манипуляции будут отталкиваться от него, как от основного.

Дальше запускаем Qt Update Manager (в папке с установленным Qt, называется «MaintanceTool») и добавляем все (либо только под целевую архитектуру) компоненты, связанные с Андроидом для вашей версии Qt.

Качаем JDK версии 8!, распаковываем куда-нить.
Кстати, подойдёт и OpenJDK 8 версии (sudo apt install openjdk-8-jre)
И сразу зададим, какую использовать версия Java, а то ошибок может быть куча:

 JAVA_HOME=/home/pavelk/Projects/ANDROID/jdk1.8.0_251/

Да, и консольку не закрываем, иначе придётся перепрописывать заново.

Создаём папку, в которой будет наш SDK:

mkdir ./SDK

и распаковываем в неё наш sdkmanager, что бы он оказался в подпапке tools (а в ней были bin и lib). Ну и начинаем с помощью него ставить все необходимые пакеты и утилиты:

cd ~/Projects/ANDROID
./SDK/tools/bin/sdkmanager --sdk_root="/home/pavelk/Projects/ANDROID/SDK" "platform-tools" "platforms;android-28"
./SDK/tools/bin/sdkmanager --sdk_root="/home/pavelk/Projects/ANDROID/SDK" "build-tools;28.0.1"

Очень внимательно читаем все лицензии, консультируемся с юристами и принимает, благославясь:

./SDK/tools/bin/sdkmanager --sdk_root="/home/pavelk/Projects/ANDROID/SDK" --license

Как Вы поняли, качаем под Android 9 (API 28 уровня), SDK будет распологаться по пути, указанным в —sdk_root
Полный список команд тут: https://developer.android.com/studio/command-line/sdkmanager.

На 64х битном Лине необходимо доставить 32х битные пакеты (но это не точно):

sudo apt install libstdc++6:i386 libgcc1:i386 zlib1g:i386 libncurses5:i386 libsdl1.2debian:i386

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

Настраиваем QtCreator:
Tools > Options > Devices > Android
Выбираем пути до OpenJDK, AndroidSDK и AndroidNDK

Ну чтож, создадим первый проект.

Как обычно создаём новый проект, в моём случае QML.
Когда доёдёт до стадии выбора комплекта — выбираем архитектуру, которая на вашем устройстве для отладки (да, тестить будем на реальном девайсе). Если не вкурсе какая именно архитектуру процессора вашего девайса, то из Play Market ставим AIDA иди CPU-z.

Сразу прожимаем «запуск», и откроется окно с предложением выбрать девайс.

Включаем на телефоне режим разработчика, для этого нужно 7 раз кликнуть в настройках, подменюшка «о телефоне» по номеру сборку.
Дальше включаем «отладку по USB» в «Настройки» -> «Система» -> «Для разработчиков»

Первый раз телефон нужно подключить по USB, потом будем по WiFi.
Выясняем его ID:

lsusb

Вытыкаем девайс и снова набираем эту же команду, сравниваем вывод и выясняем, какая строка пропала. Запоминаем значение, которое сразу за «ID» идёт (к примеру «1d6b»).

Теперь пропишем правила монтирования, что бы при подключении по USB автоматически выдавались нужные права, а так же ADBAndroid Debug Bridge — Отладочный мост Android, через него мы как раз тправляем и тлаживаем приложение на устройстве) был вкурсе нашего устройства.

echo 'SUBSYSTEM=="usb", ATTR{idVendor}=="<ID>", MODE="0666", GROUP="plugdev"' | sudo tee --append /etc/udev/rules.d/51-android.rules
echo '<ID>' | sudo tee --append ~/.android/adb_usb.ini

sudo chmod a+r /etc/udev/rules.d/51-android.rules
sudo udevadm control --reload-rules 
sudo udevadm trigger

Перезапускаем ADB

./SDK/platform-tools/adb kill-server
./SDK/platform-tools/adb start-server

Дальше приконнектимся к телефону по wifi, т.к. по проводу лень.

./SDK/platform-tools/adb tcpip 5555
./SDK/platform-tools/adb connect <IP девайса>

IP девайса можно узнать в настройках, подменюшка «о телефоне», в «общая информация».
По USB телефон теперь можно отключить и спокойно деплоить по WiFI.

Возвращаемся к Qt, жмём «Обновить список», выбираем наше устройство — справа в строке должен быть IP адрес его.

Гляньте в «консоль сборки», возможно, будут автоматически скачаны какие-либо пакеты дополнительные (возможно, при медленном соединеении, будут ошибки, поэтому запускать несколько раз придётся).

Кстати, если открыта Android Studio, то, при отладке в Qt, её придётся закрыть.

Надеюсь, сборка прошла успешно! Добро пожаловать в мир тормозов и лагов чудесный.

Пост на основе https://doc.qt.io/qt-5/android-getting-started.html

Views :

3

Qt QML OpenGL(es) application on Linux without X11/Wayland/etc (kiosk mode)

Потребовалось мне сделать управляющий софт под один девайс. То есть при загрузке он должен сразу стартовать и отображаться всё время на экране. По сути типо терминала. Зовётся это в народе «режим киоска».

Можно было бы не париться и установить обычную, десктопную систему, но очень не хотелось тащить оконный менеджер, оболочку и прочее за собой, дабы избавиться от посредников прорисовки, ну и что бы дистр с софтом весил как можно меньше. За основу был взят Ubuntu Server 19.10 (можно и ещё более облегчённый дистр).

Разумеется при попытке сразу запустить QML приложение (QML выводит всё через OpenGL) он выдал про невозможность запуска с платформой «xcb», а если указать «-platform eglfs» (то есть принудительно укажем через что выводить), выдаёт «Could not initialize egl display», то есть не может открыть дисплей (потому что eglsfs скомпилирован только для «X11»), нус, будем компилировать для работы напрямую, то есть пересобирать Qt из исходников.

Будет две машины, одна «рабочая» (на которой и будет происходить компиляция, стоит Ubuntu 19.10 Desktop), другая «тестовая» (на которой будем запускать приложение, стоит Ubuntu Server 19.10, при установке включите «OpenSSH Server» для удалённого доступа с рабочей машины).

Кстати, на тестовой машине должна быть хоть какая-нибудь видеокарта с поддержкой OpenGL 3.1. Проверить, можно поставив kmscube (заодно ставим доп. пакеты, скорее всего все они не нужны, но чтоб наверняка):

sudo apt install cmscube
sudo apt install mesa-utils
sudo aptt install libglu1-mesa freeglut3 mesa-common
cmscube

Должна запуститься демка c вращающимся кубом. Возможно, нужно будет поставить ещё драйвера (об этом в конце поста).

Переходим на рабочую.
Нужно загрузить все либы для компиляции (наверняка тут слишком много лишних, но я точно уже не помню какие именно, так что вот весь список, чтоб наверняка)

sudo apt install libglu1-mesa libglu1-mesa-dev build-essential libgl1-mesa-dev freeglut3 freeglut3-dev mesa-common-dev libglapi-mesa libosmesa6 mesa-utils libdrm-dev libgbm-dev libgbm1 libgegl-0.3-0 libgegl-dev mesa-utils-extra gegl libglfw3-dev libgles2-mesa-dev libglew1.5 libglew1.5-dev libgl1-mesa-glx

Качаем исходники

BASEPATH=/home/pavelk/QtOpenGL
mkdir $BASEPATH
cd $BASEPATH
git clone https://github.com/qt/qt5 Qt5Sources
cd Qt5Sources
perl init-repository #Успеем фильмак глянуть, пока делается
git checkout 5.14
git submodule update --recursive

Настраиваем сборку

export QT_QPA_EGLFS_INTEGRATION=eglfs_kms
./configure -platform linux-g++-64 -skip wayland -skip script -skip webengine -no-pch -no-xcb -no-xcb-xlib -no-gtk -nomake tests -nomake examples -reduce-exports -kms -eglfs -opengl es2 -opensource -release -confirm-license -make libs -prefix $BASEPATH/qt5 -v

Возможно, нужно будет добавить ещё «-qpa eglfs».
По завершению главное в выхлопе что бы было вот это:

QPA backends:
EGLFS ................................ yes
EGLFS details:
  EGLFS i.Mx6 ........................ no
  EGLFS i.Mx6 Wayland ................ no
  EGLFS EGLDevice .................... yes !!!
  EGLFS GBM .......................... yes
  EGLFS Mali ......................... no
  EGLFS Rasberry Pi .................. no
  EGL on X11 ......................... no

Та самая заветная платформа и интеграция.

Если нужно перенастроить/пересобрать, то перед запуском нужно обязательно очистить старые результаты командой: «git clean -dxf»

Ну а дальше компилируем, ставим.

make
make install

Собираться будет дооолго.

По завершению подготавливаем QtCreator, идём в «инструменты»->»параметры».

Что бы иметь возможность сразу запускать на тестовой машине:
Устройства -> Устройства, Добавить, «Обычное Linux устройство»
Название по вкусу, у меня «Test»
IP адрес устройства — айпишник тестовой машины (узнать можно залогинившись на ней и ввести «ifconfig»)
Имя пользователя — соответственно имя пользователя, которое вводили при установке.

Дальше устанавливаем ключ:
жмём «создать новую пару ключей» и запоминаем путь «файла открытого ключа» (что-то вроде «/home/pavelk/.ssh/qtc_id.pub»), прожимаем «создать и сохранить».
Далее открытый ключ нужно скопировать на тестовую машину, для этого в консольке рабочей прописываем:
«ssh-copy-id -i /home/pavelk/.ssh/qtc_id.pub user@192.168.0.193»
Только замените значения на свои.
Завершаем, проверка должна пройти без ошибок.

Комплекты -> Профили Qt, жмём Добавить
Путь: /home/pavelk/qt5/bin/qmake
Название по вкусу, у меня «OpenGLKMS»

Комплекты -> Комплекты, жмём Добавить
Компиляторы ставим те, которыми собирали.
В «Профиль Qt» выбираем созданный на предыдущем шаге
Название по вкусу, у меня «QOpenGLKMS»
Тип устройства выбираем «Обычное Linux устройство»
Устройство выбираем добавленное на предыдущем шаге.

Логинимся на тестовую машину, ставим доп. пакеты, создаём необходимые директории для библиотек Qt и переменные окружения:

sudo su
apt install mesa-utils
apt install libgles2-mesa
apt install libglfw3
apt install libharfbuzz0b
apt install libfontconfig1
apt install libmtdev1
apt install libinput10
apt install libts0

usermod -aG input user

mkdir /usr/local/lib/Qt/
mkdir /usr/local/lib/Qt/lib
chown -R user:root /usr/local/lib/Qt/

echo "/usr/local/lib/Qt/lib" > /etc/ld.so.conf.d/qt.conf
echo 'QML2_IMPORT_PATH="/usr/local/lib/Qt/qml"' >> /etc/environment
echo 'QT_PLUGIN_PATH="/usr/local/lib/plugins"' >> /etc/environment

reboot

Только имя пользователя «user» замените на своё, которое на тестовой машине.

Возвращаемся на рабочую, необходимо на тестовую скопировать либы Qt:

IP=192.168.0.193
USER=user
scp -r $BASEPATH/qt5/plugins $USER@$IP:/usr/local/lib/Qt/
scp -r $BASEPATH/qt5/qml $USER@$IP:/usr/local/lib/Qt/

scp $BASEPATH/qt5/plugins/egldeviceintegrations/libqeglfs-kms-egldevice-integration.so $USER@$IP:/usr/local/lib/Qt/plugins/egldeviceintegrations
scp $BASEPATH/qt5/lib/libQt5Core.so.5 $USER@$IP:/usr/local/lib/Qt/lib 
scp $BASEPATH/qt5/lib/libQt5Gui.so.5 $USER@$IP:/usr/local/lib/Qt/lib
scp $BASEPATH/qt5/lib/libQt5Qml.so.5 $USER@$IP:/usr/local/lib/Qt/lib
scp $BASEPATH/qt5/lib/libQt5Network.so.5 $USER@$IP:/usr/local/lib/Qt/lib
scp $BASEPATH/qt5/lib/libQt5EglFSDeviceIntegration.so.5 $USER@$IP:/usr/local/lib/Qt/lib
scp $BASEPATH/qt5/lib/libQt5DBus.so.5 $USER@$IP:/usr/local/lib/Qt/lib
scp $BASEPATH/qt5/lib/libQt5EglFsKmsSupport.so.5 $USER@$IP:/usr/local/lib/Qt/lib
scp $BASEPATH/qt5/lib/libQt5Quick.so.5 $USER@$IP:/usr/local/lib/Qt/lib
scp $BASEPATH/qt5/lib/libQt5QmlModels.so.5 $USER@$IP:/usr/local/lib/Qt/lib
scp $BASEPATH/qt5/lib/libQt5QmlWorkerScript.so.5 $USER@$IP:/usr/local/lib/Qt/lib

Имя пользователя user и айпишник замените на свои, которые для тестовой машины. Либы копируются только самые необходимые для запуска «HelloWorld», в дальнейшем Вам необходимо будет скопировать остальные.

Дальше нужно снова подключиться к тестовой и обновить список либ:

sudo ldconfig

Переходим обратно на рабочую.

Создаём тестовый проект «Приложение Qt Quick — Пустое»,
комплект выбираем который недавно создали («QOpenGLKMS «).
В *.pro файле дописываем:

INSTALLS        = target
target.path     = /home/user
CONFIG += release

Это что бы запускалось сразу на тестовой машине и релизная версия.

В main.qml

import QtQuick 2.12
import QtQuick.Window 2.12

Window {
    visible: true
    width: 640
    height: 480
    title: qsTr("Hello World")

    Rectangle {
        id: rect1
        property var colors: ["red", "blue", "orange", "gray", "green"]
        property int curColor: 0
        color: colors[curColor]
        anchors.centerIn: parent
        width: 150
        height: 150

        MouseArea {
            anchors.fill: parent
            onClicked: {
                rect1.curColor++;
                if ( rect1.curColor>=rect1.colors.length ) { 
                   rect1.curColor = 0; 
                }
                rect1.color = rect1.colors[rect1.curColor];
            }
        }
    }
}

В настройках проекта обязательно ставим «Release»(Выпуск) сборку.
Ну и запускаем =) На тестовой машине на весь экран должно запуститься приложение.

Возможно, нужно будет поставить драйвера на видюху (хз что она потащит за собой), но навсякий случай если не работает:

sudo su
apt install mesa-utils
apt install ubuntu-drivers-common
ubuntu-drivers autoinstall
apt purge gdm3
reboot

Так же, если не запускается, то на тестовой машинке попробовать прописать:

export QT_LOGGING_RULES=qt.qpa.*=true

Грузится должен qt.qpa.eglfs.kms, если грузится «emu» то проще удалить эту интеграцию: «rm /usr/local/lib/Qt/plugins/egldeviceintegrations/libqeglfs-emu-integration.so»

Так же для диагностики стоит проверить зависимости. На тестовой:

ldd ./myApp

Если все есть, то проверяем зависимости eglfs плагина:

cd /usr/local/lib/Qt/plugins/platforms/
ldd ./libqeglfs.so

Если чего-то нет, гуглим либу и как её ставить (скорее всего из разряда sudo apt isntall lib……, пару раз tab нажмите должен появится список возможных)

И запустить приложение вручную «./myApp» (оно должно быть по пути «target.path» из *.pro файла Вашего приложения при компиляции )

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

Если наблюдаются проблемы с разрешением, или есть несколько видеокарточек (дискретная и встроенная) и выводит не на ту, либо подключено несколько мониторов и нужно вывести на конкретный, то:

cd /dev/dri
ls

В списке смотрим, какие есть видеокарточки, запоминаем.
Что бы указать Qt интеграции, как и через что выводить, содаём конфигурационный файл:

nano /usr/local/lib/Qt/eglfs.json
{
 "device": "/dev/dri/card0",
 "hwcursor": true,
 "pbuffers": true,
 "outputs": [
  {
   "name": "HDMI1", "mode": "1024x768"
  }
 ]
}

Думаю, интуитивно понятно что куда и за что.
Так же полезным будет почитать документацию: https://doc.qt.io/qt-5/embedded-linux.html

Потом на тестовой машине нужно добавить переменную окружения, что бы указать, где файл настроек искать:

sudo su
echo 'QT_QPA_EGLFS_KMS_CONFIG="/usr/local/lib/Qt/eglfs.json"' >> /etc/environment
reboot

Если не работает ввод/курсор, то нужно пользователя добавить в группу input:

sudo usermod -aG input user

Ну а теперь осталось лишь сделать автозапуск приложения при включении. Для этого просто создадим свой systemd сервис:

sudo nano /etc/systemd/system/myApp.service

Description=myApp autostart
Wants=network.target
After=syslog.target network-online.target

[Service]
Type=simple
EnvironmentFile=/etc/environment
ExecStart=/home/user/myApp
Restart=on-failure
RestartSec=10
KillMode=process

[Install]
WantedBy=multi-user.target

Включаем в автозагрузку и запускаем:

sudo systemctl daemon-reload
sudo systemctl enable myApp
sudo systemctl start myApp

Ахтунг! Сервис запускается с рутовыми правами! Как сделать от имени пользователя гугл подскажет, там просто.

Вот как-то так…

Views :

71

Qt, QQuickPaintedItem отрисовка в отрицательных координатах (paint outside bounds).

Потребовалась мне тут на днях отрисовка сложных графиков в QML.
Увы, но возможностей существующих графиков не хватило — пришлось изобретать свои.

Проблема возникла с тем, что по умолчанию всё, что имеет отрицательные координаты x и y будет подвергнуто кастрации.
Да же если поставим:

setClip(false);
setFlag(QQuickItem::ItemClipsChildrenToShape, false);

И попробуем вывести круг:

void MyCircle::paint(QPainter * painter)
{
   QPainterPath path;
   path.addEllipse(-200, -200, 400, 400);

   painter->setPen(Qt::NoPen);
   painter->fillPath(path, QBrush(QColor("orange")));
}

Всё, что меньше (0, 0) будет обрезано:

Можно было бы задать размер по размеру основного окна, но мне нужно было чтобы итем холста имел конкретные размеры и положение, т.к. он на сцене будет не один.

Самое простое решение на данный момент — задать QPainter глобальную матрицу трансформации со смещением в противоположную сторону (что бы не высчитывать новые координаты при отрисовке примитивов). А компоненту задать соответственно в координатах X и Y это же значение смещения. Единственный минус — придётся делать обёртку над компонентом.
Вот так примерно:

painter->setWorldTransform(QTransform::fromTranslate(200, 200), true);
setPosition(QPoint(-200, -200));

И в QML соответственно обёртку сделать:

import QtQuick 2.12
import QtQuick.Window 2.12
import MyCircle 1.0

Window {
    visible: true
    width: 640
    height: 480
    title: qsTr("QQuickPaintedItem outside bounds")

    Rectangle {
        anchors.fill: parent
        color: "black"
    }

    Item {
        id: myCircleWrapper
        anchors.centerIn: parent
        width: 200
        height: 200

        MyCircle {
            id: myCircle
            width: parent.width
            height: parent.height
            clip: false
        }
    }
}

И результат:

Как сделать более правильно я, к сожалению, после нескольких дней раздумий и ковырянии исходников Qt не придумал…

Views :

20

Статическая сборка Qt 5.12 из исходников под Windows

Потребовалось мне тут, что бы Qt приложение было в одном exe.  Для этого придётся перекомпилировать Qt.

Качаем: Git

Качаем: Perl, версию 32х битную.

Качаем: Python 2 (У меня 2.7).

Качаем: MinGW, y меня 730 (для распаковки нужен 7Zip, запускать «C:\Programm Files (x86)\7-Zip\7zFM.exe»).

Открываем консольку (Win+R, вводим cmd), прописываем необходимые системные переменные (пути замените на свои):

set PATH=C:\MinGW\mingw730_32\bin\;%PATH%
set PATH=C:\Strawberry\perl\bin\;%PATH%

Переходим в папку, в которой будем развлекаться, качаем исходники Qt:

cd C:/QtStatic
git clone https://github.com/qt/qt5
cd qt5
perl init-repository

Конфигурируем:

configure -opensource -confirm-license -platform win32-g++ -static -release -opengl desktop -qt-zlib -qt-libpng -qt-libjpeg -nomake examples
В конфиге не включён SSL, кому нужно:
Качаем и ставим Win32OpenSSLLite
-openssl -I «c:\Qt\3dparty\openssl-1.0.2m\include» -L «c:\Qt\3dparty\openssl-1.0.2m»
Если вдруг нужно переконфигурировать и пересобрать, то нужно сначала очистить результаты предыдущих потуг:

 git submodule foreach --recursive "git clean -dfx" 
 git clean -dfx

Собираем (Часа 4) и ставим:

mingw32-make -j4
mingw32-make install

После установки настраиваем QtCreator для использования новой версии фреймворка:

В верхней менюшке Инструменты -> Параметры -> Сборка и запуск

Компиляторы -> Добавить
MinGW -> C++
Название: Qt 5.12 Static MinGW
Путь: C:\MinGW\mingw730_32\bin\c++.exe

Отладчики -> Добавить
Название: Qt 5.12 Static DBG
Путь: C:\MinGW\mingw730_32\bin\gdb.exe

Профили Qt -> Добавить
Название: Qt 5.12 Static
Путь: C:\QtStatic\qt5\qtbase\bin\qmake.exe

Комплекты -> Добавить
Название: Qt 5.12 Static
Тип устройства: Desktop
Компилятор C++: Qt 5.12 Static MinGW
Отладчик: Qt 5.12 Static DBG
Профиль Qt: Qt 5.12 Static

 Нажимаем «Применить».

Можно попробовать сделать простенький проект. В параметрах сборки и запуска поставьте «Release» т.к. мы только эту версию собрали. Так же в «*.pro» файл необходимо добавить указание на статическую сборку и линковку libGCC.

QMAKE_LFLAGS += -static -static-libgcc

Ну вот, как-то так =)

Views :

2047

Qt, вызов функции с ограничением по времени выполнения (QtConcurrent::run timeout).

Потребовалось в одном проекте в критическом к скорости выполнения месте дёргать функции сторонней библиотеки, но загвоздка в том, что эти функции внутри ещё и дожидаются результата в цикле/магия. Мне от неё важно только получить код ошибки (если сразу возник), другой результат не так важен (потом запрашивается отдельно).

В общем задача: запустить функцию, по возможности дождаться результат, но не дольше N, если не удалось (время вышло), поставить флаг, что не удалось, что бы потом запросить отдельно.

Можно было бы вообще всё использование вынести в отдельный поток, но городить ради одного места неохото, зато родились вот такие извращения:

  1. В Qt есть QtConcurrent, с помощью которого можно запустить функцию в отдельном потоке,
  2. Так как нам желательно сразу получить результат не выходя из функции (в случае ошибки вызываемая функция особо не задерживается), то можно прописать future.result(), но тогда мы будем ждать до победного, а нам нужно ограничить время выполнения, поэтому
  3. Используем QTimer, что бы по истечению заданного времени завершить выполнение, но и тут облом — мы не можем принудительно завершить выполнение «QtConcurrent::run», (т.к. вызываемая функция может не освободить память/не закрыть доступ к файлу да и вообще хз что). Поэтому завершать выполнение не будем, а тупо забьём на него — пусть там себе в параллельном потоке выполняется, а мы тем временем пойдём дальше, но тогда будет необходимо использовать сигналы, что бы дать понять, когда пора выходить из функции по истечению времени, а когда функция вернула результат, поэтому
  4. Используем QFutureWatcher, что бы подписаться на сигнал «finished» если функция выполнилась.
  5. Ну а что бы ждать сигнала от таймера, либо сигнала о завершении вызываемой функции и не выходить до этого из текущей функции используем  QEventLoop.  Как только тот или другой сигнал будет вызван и обработан, то завершаем цикл.

Из преимуществ: выполнение происходит в отдельном потоке, поэтому не затрагиваем основной процесс, в котором происходит вызов функции.

Из недостатков: мы не управляем параллельным процессом в полной мере, т.е. не можем принудительно завершить процесс и он будет болтаться в памяти до исключения, завершения или посинения (если функция «зациклится»).

В общем, вот так:

#include <QtConcurrent/QtConcurrentRun>
#include <QFuture>
#include <QFutureWatcher>
#include <QEventLoop>
#include <QTimer>
#include <QDebug>

....

void AppCore::runAsync()
{
    qDebug()<<"Run async";

    QString r;
    QFuture<QString> f;

    try {
        f = QtConcurrent::run(this, &AppCore::asyncFunction);
    } catch(...) {
        qDebug()<<"ERROR";
    }

    QFutureWatcher<QString> w;
    QEventLoop l;
    QTimer t;

    connect(&w, &QFutureWatcher<QString>::finished, [&l, &r, &w](){
        r = w.result();
        qDebug()<<"From connection 1.";
        l.quit();
    });

    connect(&t, &QTimer::timeout, [&l, &r](){
        r = "TIME OUT!";
        qDebug()<<"From connection 2.";
        l.quit();
    });

    w.setFuture(f);
    t.start(2000);
    l.exec();

    qDebug()<<"RESULT:"<<r;

}

/**
* @brief Функция, которая будет выполнятся в фоновом потоке
* @return
*/
QString AppCore::asyncFunction()
{
    qDebug()<<"In async function.";
    QThread::sleep(5);

    qDebug()<<"ASYNC FUNCTION COMPLETED!";

    return QString("COMPLETED NORMAL!");
}

Вывод:

Run async
In async function.
From connection 2.
RESULT: "TIME OUT!"
ASYNC FUNCTION COMPLETED!

Т.е. вышло время, мы получили результат, что время вышла, но сама вызываемая функция в параллельном потоке всё равно выполнилась до конца.

Ну и упростим это до макроса, что бы иногда использовать:

/**
* Выполняем функцию в параллельном потоке и отдаём результат,
* если не выполнится за время timeOut_ms, то отдаём timeOut_result
* QtConcurrentRunTimeOut(int, myIntRes, this, &MyClass::myFunction, 2000, -100);
* QtConcurrentRunTimeOut(int, myIntRes, this, &MyClass::myFunctionWithParams, 2000, -100,  14, 88);
* qDebug()<<"RESULT:"<<myIntRes;
* Need include
* #include <QtConcurrent/QtConcurrentRun>
* #include <QFuture>
* #include <QFutureWatcher>
* #include <QEventLoop>
* #include <QTimer>
*/
#define QtConcurrentRunTimeOut(resultType, res, object, functionPointer, timeOut_ms, timeOut_result, ...)\
    resultType _r##res;\
    QFuture<resultType> _f##res;\
    _f##res = QtConcurrent::run(object, functionPointer,##__VA_ARGS__);\
    QFutureWatcher<resultType> _w##res;\
    QEventLoop _l##res;\
    QTimer _t##res;\
    connect(&_w##res, &QFutureWatcher<resultType>::finished, [&_l##res, &_r##res, &_w##res](){\
        _r##res = _w##res.result();\
        _l##res.quit();\
    });\
    connect(&_t##res, &QTimer::timeout, [&_l##res, &_r##res](){\
        _r##res = timeOut_result;\
        _l##res.quit();\
    });\
    _w##res.setFuture(_f##res);\
    _t##res.start(timeOut_ms);\
    _l##res.exec();\
    resultType res=_r##res;

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

Вот как-то так =) 

Views :

226

Вылеты Q_ASSERT(c->sender == q_ptr);

Появилась достаточно странная бага — вылеты при отладке и чуть реже при релизе с этой ошибкой.

Сколько бы я не пытался выяснить конкретное место ошибки — везде был облом, пока не понял, что недавно одна из библиотек обновилась.

Чтож, виновник теоретический найден, но вот поиски что именно не так доставило несколько геммора. 

В общем причина была в незакрытом  #pragma pack(8), заменим его на #pragma pack(push, 1)  тем самым запомнив предыдущие настройки, а после объявлений структур восстановим настройки #pragma pack(pop) что бы Qt сума не сходил.

 

 

Views :

145

Модульное тестирование (Unit test) в Qt

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

И так, имеем проект с подпроектами. Хотим тесты. 

Следуя мануалу Qt нужно создать новый проект Unit test, в нём класс для теста, с помощью мастера создания Qt сделает базовый скелет.

Но вот тут начинаются проблемы. Следуя задумке Qt:

  1. Один проект — один класс для теста. Мда…
  2. С помощью макроса QTEST_MAIN (или QTEST_APPLESS_MAIN) создаётся функция main.
  3. Поэтому каждый проект соответственно компилируется в бинарник
  4. Соответственно каждый тест запускается отдельно и не зависимо от други

Мне кажется такая организация немного не логичной.  

Так как если класс сильно зависит от других  (вообще это не айс, но всякое бывает), то придётся чуть ли не весь основной проект добавлять в инклуды и так каждый тест, ну и если класс использует QML, то тут точно в main нужно прописывать инициализацию qml, установку всех свойств и переменных и т.д., в общем, это у меня сначала и отбило всякое желание делать тесты.

Но так нужно, что бы в QtCreator работала панель «Tests», в которой удобно просматривать результаты тестирования и выборочно запускать сами тесты, вот так это выглядит:

Можно, конечно,  реализовать все классы тестов просто в  отдельной папке проекта (например Tests), убрать все макрос QTEST_MAIN, и запускать все тесты из функции main основного проекта, но тут минус в том, что они будут выполняться при любом запуске проекта, ну и выборочный запуск будет работать через жопу, либо вообще не работать — только все сразу. 

Вот так, например:

void main()
{
    ...
    MyTestClass1 tc1;
    if (QTest::qExec(&tc1, argc, argv)>0) return 42;
    
    MyTestClass2 tc2;
    if (QTest::qExec(&tc2, argc, argv)>0) return 42;
    ...
}
        
        
        

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

Кому достаточно такого поведения, можно дальше не париться =)

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

Решение такое:

Сделаем наш файл проекта (*.pro) подключаемым/шаблонным (*.pri) что бы его можно было инклудить в тестовые проекты,
для этого в *.pro  файле убираем из SOURCES  main.cpp (её мы будем подключать в тестовые проекты отдельно) и всё из *.pro файла переносим в *.pri файл (сначала создав обычный пустой текстовый файл),
потом в *.pri файле в самом верху прописываем:

VPATH += $$PWD #Что бы файлы подключались относительно оригинального расположения файла
INCLUDEPATH += $$PWD

В *.pro файле основного проекта прописываем:

include(common.pri)  #Подключаем основной класс проекта
SOURCES += main.cpp \  #Как обычно добавим в исходники наш основной main

Ну и теперь осталось изменить немного функцию main, что бы когда она была в основном проекте, то запускалась бы как обычно, а когда была в тестовом проекте, запускала бы тест.

#include <QApplication>
#include <QQmlApplicationEngine>
......

int main(int argc, char *argv[])
{
    QApplication app(argc, argv);
    QQmlApplicationEngine engine;
    engine.load(QUrl(QStringLiteral("qrc:/main/main.qml")));
    .....

   //-- Даём возможность инклудить нас в тесты
    #ifdef MY_TEST
        return runTest(argc, argv);
    #else
        return app.exec();
    #endif
}

С помощью проверки, объявлен ли макрос запускаем на исполнение тест, иначе всё как обычно.

Такой финт ушами нужен, потому что QTestLib сканирует классы на наличие  «QTest::qExec(….)» и, если у нас этого не будет в самом классе, то тест не будет доступен в панельке, поэтому объявление функции запуска будет находиться в самом тестовом классе, а запуск этой функции из main.

Так, теперь как использовать:

В основном проекте создаёте проект с поддиректориями, называете, например «Tests», в этом подпроекте с помощью мастера создания создаёте уже проект «Unit test», например «test1».

В *.pro файле (у нас «test1.pro») тестового проекта прописываем:

include(../../MyProject/common.pri)

И в *.cpp тестовом классе подключаем нашу main функцию для запуска основного проекта и теста:

int runTest(int argc, char *argv[]) //-- Нужно, что бы парсер тестов нашёл этот тест, поэтому запускаем мы его из main
{
    MyTestClassName t;
    return QTest::qExec(&t, argc, argv);
}

#define MY_TEST
#include "../MyProject/main.cpp"

Надеюсь, принцип понятен. Только с относительными путями не наебитесь 😀

Вот теперь всё тестится, управляется, и да же желание тесты писать появилось =)

 

 

 

Views :

1148

Использование интерфейсов классов в Qt и QML

Привет!

Порою удобнее в QML работать именно с интерфейсом класса, а так же иметь возможность засунуть его в QVariant.  

Разумеется простым способом в «лоб» не получится, т.к. Qt в QML работает с QObject, а мы от него не унаследовались и никакой информации для метасистемы не дали.

Долго я копался в недрах метасистемы Qt, уж собирался делать костыли, но наткнулся на макрос Q_DECLARE_INTERFACE.

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

Пишем:

#ifndef IINTERFACE_H
#define IINTERFACE_H

#include <QObject>


class IInterface {
public:
    virtual QString myProperty() const =0;
    virtual void setMyProperty(QString myProperty) =0;
    virtual void myPropertyChanged(QString myProperty) =0;
};

Q_DECLARE_INTERFACE(IInterface, "pavelk.iinterface")


#endif // IINTERFACE_H

Обратите внимание на строку с «Q_DECLARE_INTERFACE» — тем самым мы даём понять метаобъектной системе Qt, что это интерфейс, что бы он прописал необходимые функции по получению исходного класса.

Ну и сам класс:

#ifndef MYCLASS_H
#define MYCLASS_H

#include <QObject>

#include "iinterface.h"

class MyClass : public QObject, public IInterface
{
    Q_OBJECT
    Q_INTERFACES(IInterface)
    Q_PROPERTY(QString myProperty READ myProperty WRITE setMyProperty NOTIFY myPropertyChanged)
public:
    explicit MyClass(QObject *parent = nullptr);

    QString myProperty() const;

signals:
    void myPropertyChanged(QString myProperty);

public slots:
    void setMyProperty(QString myProperty);

private:
    QString m_myProperty;
};

#endif // MYCLASS_H

Обратите внимание на строку с «Q_INTERFACES(IInterface)» — тем самым мы даём знать Qt как именно преобразовывать этот класс к указанному интерфейсу. Кстати, можно наследоваться сразу от нескольких интерфейсов — просто пропишите через пробел их все.

Ну и теперь самое интересное. Преобразовываем класс к интерфейсу и передаём этот интерфейс в QML

   MyClass * myClass = new MyClass(0);
   IInterface * interface = myClass;
   engine.rootObjects().at(0)->setProperty("myClassInterface", qVariantFromValue( dynamic_cast<QObject*>(interface) ));

Напрямую в QVariant интерфейс засовывать нельзя, т.к. он не знает необходимой информации, поэтому преобразовываем сначала в QObject*, а благодаря тому, что мы прописал Q_DECLARE_INTERFACE метасистема знает как работать с этим интерфейсом.

Полный код примера тут:  https://github.com/Riflio/QMLInterfaces

Вот как-то так =)

Views :

632

Qt, QEventLoop and connect/disconnect lambda function

Приветствую!

Кому некогда, можно сразу прыгнуть в конец к итогу.

Бывают ситуации, когда нужно синхронно дождаться завершения асинхронного действия, при этом не подвешивая основной поток (например, не продолжать выполнение функции, пока ответ в QTCPSocket onReadyRead от сервера не придёт).   

В нашем случае для примера давайте подождём с выполнением функции, пока таймер не досчитает до 5. 

Делаем основу:

#ifndef APPCORE_H
#define APPCORE_H

#include <QObject>
#include <QTimer>
#include <QGuiApplication>
#include <QDebug>

class AppCore : public QObject
{
    Q_OBJECT
public:
    explicit AppCore(QObject *parent = nullptr): QObject(parent)
    {
        _timer = new QTimer(this);
        _timer->setSingleShot(true); //-- Срабатывать только один раз

    }

    void waitFunction()
    {
        qDebug()<<"Timer BEGIN";
        _timer->start(5000); //-- 5 секунд в миллисекундах


        qDebug()<<"Timer END";
    }

signals:

public slots:

private:
    QTimer * _timer;
};

#endif // APPCORE_H

Но если мы запустим так, то вывод  «Timer END» произойдёт без какой-либо задержки, т.к. таймер ведёт отсчёт асинхронно в другом потоке.

Решением в «лоб» было бы подписаться на событие срабатывания таймера, объявить флаг срабатывания и в бесконечном цикле отслеживать его, как-то так, например:

#ifndef APPCORE_H
#define APPCORE_H

#include <QObject>
#include <QTimer>
#include <QDebug>
#include <QGuiApplication>

class AppCore : public QObject
{
    Q_OBJECT
public:
    explicit AppCore(QObject *parent = nullptr): QObject(parent)
    {
        _timer = new QTimer(this);
        _timer->setSingleShot(true); //-- Срабатывать только один раз
        connect(_timer, &QTimer::timeout, this, &AppCore::onTimeOut);

    }

    void waitFunction()
    {
        qDebug()<<"Timer BEGIN";
        _timer->start(5000); //-- 5 секунд в миллисекундах

        while (true) {
            if (_timeOut) {
                break;
            }
            QGuiApplication::processEvents();
        }

        qDebug()<<"Timer END";
    }

public slots:
    void onTimeOut()
    {
        _timeOut = true;
    }

private:
    QTimer * _timer;
    bool _timeOut=false;
};

#endif // APPCORE_H

Кстати, если бы мы не указали «QGuiApplication::processEvents();«, то слот «onTimeOut()» не вызвался бы никогда, т.к. цикл у нас бесконечный, а так мы заставляем всё таки обработать события, а заодно и не подвешивать сильно интерфейс. 

Но решение это слишком топорное и не красивое. Что бы не использовать бесконечные циклы у Qt есть QEventLoop.  Выполнение функции приостанавливается методом «exec()» и QEventLoop ждёт, пока не будет вызван метод «exit()» и лишь потом продолжается.

Делаем:

#ifndef APPCORE_H
#define APPCORE_H

#include <QObject>
#include <QTimer>
#include <QDebug>
#include <QGuiApplication>
#include <QEventLoop>

class AppCore : public QObject
{
    Q_OBJECT
public:
    explicit AppCore(QObject *parent = nullptr): QObject(parent)
    {
        _timer = new QTimer(this);
        _timer->setSingleShot(true); //-- Срабатывать только один раз
        connect(_timer, &QTimer::timeout, this, &AppCore::onTimeOut);

    }

    void waitFunction()
    {
        qDebug()<<"Timer BEGIN";

        _timer->start(5000); //-- 5 секунд в миллисекундах
        _loop.exec(); //-- Ждём, пока будет вызван exit();

        qDebug()<<"Timer END";
    }

public slots:
    void onTimeOut()
    {
        _loop.exit();
    }

private:
    QTimer * _timer;
    QEventLoop _loop;
};

#endif // APPCORE_H

Стало чуть-чуть красивее, но у нас всё ещё висит одноразовый слот «onTimeOut()» и одноразовая переменная «_loop«.  Это сейчас она одна, а если в нашем классе нужно в 5 разных местах дожидаться ответов? Как-то по 5 одноразовых слотов и переменных иметь некрасиво…

Благо в Qt начиная с 5 версии появилась возможность при соединении сигнал-слота вместо слота использовать лямбда-функцию, этой фишкой мы и воспользуемся, что бы избавиться он объявления глобального слота «onTimeOut()» и переменной «_loop»

Делаем: 

#ifndef APPCORE_H
#define APPCORE_H

#include <QObject>
#include <QTimer>
#include <QDebug>
#include <QGuiApplication>
#include <QEventLoop>

class AppCore : public QObject
{
    Q_OBJECT
public:
    explicit AppCore(QObject *parent = nullptr): QObject(parent)
    {
        _timer = new QTimer(this);
        _timer->setSingleShot(true); //-- Срабатывать только один раз
    }

    void waitFunction()
    {
        qDebug()<<"Timer BEGIN";

        QEventLoop _loop;

        connect(_timer, &QTimer::timeout, [&](){
            _loop.exit();
        });

        _timer->start(5000); //-- 5 секунд в миллисекундах
        _loop.exec(); //-- Ждём, пока будет вызван exit();

        qDebug()<<"Timer END";
    }

private:
    QTimer * _timer;

};

#endif // APPCORE_H

Запускаем и ровно через 5 секунд после «Timer BEGIN» у нас выведется «Timer END»  и вроде бы добились чего хотели, но тут есть одна тонкость. Для наглядности я в лямбду добавлю вывод информации о срабатывании, вот так теперь она выглядит::

connect(_timer, &QTimer::timeout, [&_loop](){
    qDebug()<<"TIME OUT!";
    _loop.exit();
});

Допустим нам нужно в нескольких местах ждать ответа, и мы два раза вызываем функцию:

    ....
    waitFunction();
    waitFunction();
    ....

Вывод будет такой:

Timer BEGIN
TIME OUT!
Timer END
<br>Timer BEGIN
TIME OUT!
TIME OUT!
Timer END

Как видите, «TIME OUT» после второго вызова вывелось два раза! А если бы мы функцию «waitFunction()» вызвали 10 раз, то соответственно «TIME OUT» вывелось бы то же 10 раз подряд.  Так явно не должно быть! В чём дело?  А дело в том, что лямбда функция автоматически не отключается! Если забыть про эту фишку можно нарваться в том числе и на «SIGSEGV Segmentation fault», сегфолт короче. 

Решение — это не забывать отключать (disconnect signal lambda) сигнал от лямбды, но просто так это сделать не получится, т.к. это всё таки лямбда, нужно запоминать информацию, которую возвращает метод «QMetaObject::Connection conn = connet(….)«, а по ней отключать «disconnect(conn)«. 

Делаем:

void waitFunction()
{
    qDebug()<<"Timer BEGIN";

    QEventLoop _loop;

    QMetaObject::Connection conn = connect(_timer, &QTimer::timeout, [&_loop](){
        qDebug()<<"TIME OUT!";
        _loop.exit();
    });

    _timer->start(5000); //-- 5 секунд в миллисекундах
    _loop.exec(); //-- Ждём, пока будет вызван exit();

    disconnect(conn);

    qDebug()<<"Timer END";
}

Срабатывать будет  один раз и отключаться, вывод придёт в норму:

Timer BEGIN
TIME OUT!
Timer END

Timer BEGIN
TIME OUT!
Timer END

Но об  «disconnect(….)»  можно забыть, поэтому предлагаю использовать умные указатели, а именно QSharedPointer, но у него нужно не забыть реализовать отключение, т.к. сам по себе он это делать не умеет, а так как писанины получается многовато, поэтому предлагаю запилить макрос.

Итоговый код:

#ifndef APPCORE_H
#define APPCORE_H

#include <QObject>
#include <QTimer>
#include <QDebug>
#include <QGuiApplication>
#include <QEventLoop>
#include <QSharedPointer>

class AppCore : public QObject
{
    Q_OBJECT
public:
    explicit AppCore(QObject *parent = nullptr): QObject(parent)
    {
        _timer = new QTimer(this);
        _timer->setSingleShot(true); //-- Срабатывать только один раз
    }

    #define AutoDisconnect(l) \
        QSharedPointer<QMetaObject::Connection> l = QSharedPointer<QMetaObject::Connection>(\
            new QMetaObject::Connection(), \
            [](QMetaObject::Connection * conn) { /*QSharedPointer сам по себе не производит отключения при удалении*/ \
                QObject::disconnect(*conn);\
            }\
        ); *l //-- Use AutoDisconnect(conn1) = connect(....);

    void waitFunction()
    {
        qDebug()<<"Timer BEGIN";

        QEventLoop _loop;

        AutoDisconnect(conn) = connect(_timer, &QTimer::timeout, [&_loop](){
            qDebug()<<"TIME OUT!";
            _loop.exit();
        });

        _timer->start(5000); //-- 5 секунд в миллисекундах
        _loop.exec(); //-- Ждём, пока будет вызван exit();

        qDebug()<<"Timer END";
    }

private:
    QTimer * _timer;

};

#endif // APPCORE_H

Вот как-то так =)

P.S. Макросы не зло, нужно просто уметь их готовить 😉

Views :

665

Layout.fillWidth: true и Layout.preferredWidth/Layout.minimumWidth зависимость (очередная хитрость)

Сталкиваюсь иногда с некоторыми хитростями в QML, о которых, по всей видимости, приходится только догадываться, ибо то ли я проглядел это в документации, то ли этого действительно в ней не указано.

Так вот, задача: нужно три колонки одинаковой ширины.

Делаем:

import QtQuick 2.9
import QtQuick.Window 2.2
import QtQuick.Layouts 1.3

Window {
    visible: true
    width: 640
    height: 480
    title: qsTr("QMLTips&Tricks24")

    RowLayout {
        anchors.fill: parent
        spacing: 0

        Rectangle {
            color: "blue"
            Layout.fillHeight: true
            Layout.fillWidth: true            
        }

        Rectangle {
            color: "orange"
            Layout.fillHeight: true
            Layout.fillWidth: true
        }


        Rectangle{
            color: "green"
            Layout.fillHeight: true
            Layout.fillWidth: true            
        }

    }
}

Соответственно на выходе получаем:

Получилось как и задумывали.

Обновим задачу:  Оранжевая колонка должна иметь предпочтительную ширину 200 пикселей.
Делаем:

Rectangle {
    color: "orange"
    Layout.fillHeight: true
    Layout.fillWidth: true
    Layout.preferredWidth: 200
}

Получаем:

Что-то не то, да..? 

Вот тут начинается самое интересное.

Дело в том, что Layout.prefferedWidth (а так же Layout.minimumWidth) управляет пропорционально шириной относительно соседей, когда задано Layout.fillWidth: true

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

Делаем:

Rectangle {
    color: "blue"
    Layout.fillHeight: true
    Layout.fillWidth: true
    Layout.preferredWidth: 200
}

Rectangle {
    color: "orange"
    Layout.fillHeight: true
    Layout.fillWidth: true
    Layout.preferredWidth: 200
}

Rectangle{
    color: "green"
    Layout.fillHeight: true
    Layout.fillWidth: true
    Layout.preferredWidth: 200
}

Получаем:

То есть как и задумывали, три одинаковые колонки.

Теперь наглядный пример насчёт пропорционально соседям изменяемости размеров. Если мы у синего прямоугольника зададим желаемую ширину в 50, а у зелёного 100, то соответственно синий будет в 4 раза меньше оранжевого (200/50=4), а зелёный буде в два раза меньше оранжевого (200/100=2). 

То есть родитель Layout (RowLayout/ColumnLayout/GridLayout) берёт от потомков наибольший желаемый размер и относительно него пропорционально выставляет ширину всем потомкам.
Повторюсь, что так QML себя ведёт, только когда задано Layout.fillWidth: true

Делаем:

Rectangle {
    color: "blue"
    Layout.fillHeight: true
    Layout.fillWidth: true
    Layout.preferredWidth: 50
}

Rectangle {
    color: "orange"
    Layout.fillHeight: true
    Layout.fillWidth: true
    Layout.preferredWidth: 200
}

Rectangle{
    color: "green"
    Layout.fillHeight: true
    Layout.fillWidth: true
    Layout.preferredWidth: 100
}

Получаем:

Короче, считаем, что при указании preferredWidth, minimumWidth мы работаем с пропорциями относительно остальных в одном контейнере и всё. 

Почему именно так, а не иначе?  

По-моему как раз для того, что бы можно было задать поведение при растягивании/сжимании…

 

Аналогичная ситуация произойдёт, если мы оранжевой колонке захотим указать minimumWidth: 100 при fillWidth:true

Что делать, если нужно, что бы все колонки имели одинаковую ширину и заполняли всё пространство (т.е. fillWidth: true), но при этом у них (у всех или у некоторых) должна быть задана разная минимальная ширина? 

Я в таком случае прописываю у всех:  preferredWidth: 1000;  что бы желательная ширина у всех была одинаковая и обязательно больше, чем минимальная, иначе учитываться не будет (логично, да?)

Надеюсь, теперь больше с этим проблем не возникнет.

Кстати, такое же поведение будет если у компонента задано свойство implicitWidth или implicitHeight, потому что если мы не задали явно Layout.preferredWidth или  Layout.fillHeight, то берутся как раз они. Наверное вы спрашиваете: как быть, если это не просто прямоугольник, а какой-то компонент? То всё просто — оберните его в Item или Rectangle или задайте явно Layout.preferredWidth

Кстати, вот документация на лэйауты: тынц.

Вот как-то так =)

Views :

384