KDAB

Bind QML Values across an Arbitrary Number of Elements

Thu, 19 Mar 2026 08:26:39 GMT

Bind QML Values across an Arbitrary Number of Elements

A while back I was writing a program that could instantiate an arbitrary number of windows containing controls synchronized across them. How a control would be synchronized would depend on a condition that determined which window instances would be linked to other instances. There are a few ways this could be implemented. In this entry I'll share my approach, in which I used a singleton C++ class serving as a message broker to bind properties across window instances.

Properties bound across multiple instances of a window

The App: Display to Light Panels

The software I wrote this for is a small app that allows you to have many windows open, all synchronized to display a single color on a per-monitor basis. The idea behind this is for users to adjust the light that comes off their monitors and use it to illuminate their faces when recording a video or taking pictures. By having individual windows be synchronized, users can continue to interact with the computer through their displays (rather inconveniently), while simultaneously using them to illuminate themselves.

This is, by no means, a replacement for a proper recording setup. Some of you will know that a light source placed in front of the subject can serve as either a nice "fill light" or a "scary spotlight", depending on the height and size of the source. Therefore, this should be complemented with other sources of light; ideally ambient light and a top light, to achieve a nice look. If the app seems useful to you, there's a link to it at the end of this article. That's enough gaffer speak for today. Let's talk about the code.

The Code

When writing code, one of my main concerns is always long-term maintainability. For that reason, I prefer to connect different parts of code in explicit, and easy to follow ways. One of such ways is passing values through a hierarchy of components; that is generally easy to track and produces well performing code. However, that approach can become unviable when connecting dynamically instantiated items to other dynamically instantiated items. A better solution in this instance is to use signals and slots to interconnect the items via a message broker class, done in C++. Each item would have a model or backend class in C++ and those classes would have the message broker in common. Lastly, the properties would be exposed to QML through Q_PROPERTY and updated via your control's signal handlers.

Message Broker Singleton

The message broker needs to be a singleton. That way there's only one instance of the broker in memory and all instantiated objects interface with the same broker. Our message broker only needs to provide the signals that will be used for routing properties. The actual connections that the routing involves are to be done from the outside. As such, a broker class would look like this:

// internalmessagebroker.hpp
// Singleton broker class contains signals that serve as pipes
// for different parts of a program to communicate with each other.

#pragma once

#include <QObject>

class InternalMessageBroker : public QObject
{
    Q_OBJECT

// Hide regular constructor
private:
    InternalMessageBroker() = default;

public:
    // Disable copy constructor
    InternalMessageBroker(const InternalMessageBroker& obj) = delete;
    InternalMessageBroker& operator=(InternalMessageBroker const&) = delete;
    static std::shared_ptr<InternalMessageBroker> instance()
    {
        static std::shared_ptr<InternalMessageBroker> sharedPtr{new InternalMessageBroker};
        return sharedPtr;
    }

// This is where all the signals would go
signals:
    void broadcastAPropertyChange(int value, bool broadcast);
};

Connecting Properties

Then we have the class or classes that would connect the properties together. On my Display Panels app, all controls and visual features come from QML, meaning I only have to concern myself with interconnecting the properties. To that end, I've created a class based on QObject and instantiated it within the delegate of a QML Instantiator. This class is only for managing property data, so I refer to it as a model class, called PropertiesModel:

// Main.qml
// Here are 3 windows, each with a PropertiesModel,
// that allows them all to share a binding to aProperty
// across all window instantiatons.

import QtQuick
import QtQuick.Window
import QtQuick.Layouts
import QtQuick.Controls

import com.kdab.example

Item {
    Instantiator {
        model: 3
        delegate: Window {
            PropertiesModel {
                id: propertiesModel
                aProperty: 1
            }
            ColumnLayout {
                anchors.fill: parent
                Text {
                    text: propertiesModel.aProperty
                }
                Slider {
                    id: hueSlider
                    value: propertiesModel.aProperty
                    Layout.fillWidth: true
                    onMoved: {
                        propertiesModel.aProperty = value;
                    }
                }
            }
        }
    }
}

Each property of our class is to be declared using a Q_PROPERTY macro with a getter, a setter, and a notifier. The getter and the notifier have nothing out of the ordinary...

// An ordinary getter
int PropertiesModel::aProperty()
{
    return m_aProperty;
}

// An ordinary notifier, form propertiesmodel.h
signals:
    void aPropertyChanged();

However, the setter must be able to distinguish between when its call is the product of a user interaction and when it comes from the message broker. We accomplish this by having the setter accept a boolean argument (broadcast) that will be used to determine whether the value being set should be sent through the message broker or notified back to QML for the UI to be updated. When a setter is first called, the value being set should be broadcasted and only on its way back should the UI be updated.

There are a few ways we could make sure that the value is always broadcasted first. We could set broadcast to true by default, or have two setter functions: a private one taking in both the value and broadcast arguments and a public one that only takes-in the value and calls the private function with broadcast set to true. Another option is to have broadcast be an enum with only two possible values. That would produce more readable code, however, I didn't worry about that in my code because broadcast is only to be used on calls to the private setter.

Upon the private setter being called by the public setter, it will emit the broker's broadcast signal and that signal will in turn call the calling private setter for a second time (as well as the private setters of all other instances of PropertiesModel; those being called for the first time). When the private setter calls the broker that calls back to the private setter, it also passes broadcast set to false. All other instances will then evaluate the value of broadcast to be false determining that the UIs should be updated and preventing an infinite loop.

// Private setter implementation for a property that's being broadcasted
void PropertiesModel::setAProperty(const int value, const bool broadcast)
{
    if (broadcast)
        emit m_broker.get()->broadcastAPropertyChange(value, false);
    else if (m_currentScreen == screenName) {
        m_aProperty = value;
        emit screenSaturationChanged();
    }
}

// Publicly exposed setter prevents the broadcast argument from being
// specified by other callers
void PropertiesModel::setAProperty(const int value)
{
    // Always broadcast properties not being set by the message broker
    setAProperty(value, true);
}

To complete this loop as described, we need to connect the signal from the broker to the private setter of the PropertiesModel class whenever a new copy is instantiated. The best place to accomplish that is from the class' constructor, like so:

// The constructor is used to connect signals from the broker to setter properties
PropertiesModel::PropertiesModel(QObject* parent)
    : QObject { parent }
{
    m_mb = InternalMessageBroker::instance();
    // Connections take place after the class has been instantiated
    // and its QML properties parsed.
    QTimer::singleShot(0, this, [this] () {
        connect(m_mb.get(), &InternalMessageBroker::aPropertyChange,
        this, &ScreenModel::setAProperty);
    });
}

QTimer to Delay Initialization

If you've been reading the blocks of code that accompany this article, you may be wondering "Why is there a singleShot QTimer there?" When the PropertiesModel class is instantiated via QML, any connected properties that have values assigned from QML code will trigger the Q_PROPERTY's setter function. This will happen once per instantiation. If the broker were connected, it would broadcast the value set to all currently instantiated instances every single time that a new instance is added. To prevent that, we must not make the connection to the broker until after a class has been fully initialized. A single shot timer can be used to accomplish that; setting its delay to 0 will ensure that it is run immediately after all properties have been evaluated.

In the end, this is what the PropertyModel header would look like:

// propertiesmodel.h
#pragma once

#include "internalmessagebroker.hpp"

#include <QQmlEngine>

class PropertiesModel : public QObject {
    Q_OBJECT
    QML_ELEMENT

    Q_PROPERTY(int aProperty READ aProperty WRITE setAProperty NOTIFY aPropertyChanged FINAL)
public:
    explicit PropertiesModel(QObject* parent = nullptr);

    int aProperty();
    void setAProperty(const int value);

signals:
    void aPropertyChanged();

private: 
    void setAProperty(const int value, const bool broadcast);

    std::shared_ptr<InternalMessageBroker> m_mb;
    int m_aProperty;
};

Conditional propagation

If a condition must be met for the propagated value to result in an update, then, in addition to value and broadcast, you should also broadcast any other values that are required to for such condition to be met. Pass those as arguments to the setter's and the broker's signal. Condition validation would then take place within the base case of the private setter. Here's a commented snippet of what that looks like on the Display to Light Panels app that this article was based on:

// In the original code what here I named broadcast used to be named spread.
void ScreenModel::setScreenHue(const int hue, const bool spread=true, const QString &screenName="s")
{
    if (spread)
        emit m_mb.get()->spreadHueChange(hue, false, m_currentScreen);
    // The incoming value is only accepted if screenName matches the screen
    // that the window is at and discarded otherwise.
    else if (m_currentScreen == screenName) {
        m_screens[m_currentScreen].hue = hue;
        emit screenHueChanged();
    }
}

Properties bound across instances of a window

Real World Example

For a real world application, you can read the code for Display to Light Panels, the app that inspired this article, at: https://github.com/Cuperino/Display-to-Light-Panels

If you need help solving architecture problems, such as this one, reach out to us and we will gladly find ways in which we can help.

The post Bind QML Values across an Arbitrary Number of Elements appeared first on KDAB.

Automating Repetitive GUI Interactions in Embedded Development with Spix

Thu, 19 Feb 2026 08:18:12 GMT

Automating Repetitive GUI Interactions in Embedded Development with Spix

As Embedded Software Developers, we all know the pain: you make a code change, rebuild your project, restart the application - and then spend precious seconds repeating the same five clicks just to reach the screen you want to test. Add a login dialog on top of it, and suddenly those seconds turn into minutes. Multiply that by a hundred iterations per day, and it’s clear: this workflow is frustrating, error-prone, and a waste of valuable development time.

In this article, we’ll look at how to automate these repetitive steps using Spix, an open-source tool for GUI automation in Qt/QML applications. We’ll cover setup, usage scenarios, and how Spix can be integrated into your workflow to save hours of clicking, typing, and waiting.

The Problem: Click Fatigue in GUI Testing

Imagine this:

You start your application.
The login screen appears.
You enter your username and password.
You click "Login".
Only then do you finally reach the UI where you can verify whether your code changes worked.

This is fine the first few times - but if you’re doing it 100+ times a day, it becomes a serious bottleneck. While features like hot reload can help in some cases, they aren’t always applicable - especially when structural changes are involved or when you must work with "real" production data.

So, what’s the alternative?

The Solution: Automating GUI Input with Spix

Spix allows you to control your Qt/QML applications programmatically. Using scripts (typically Python), you can automatically:

Insert text into input fields
Click buttons
Wait for UI elements to appear
Take and compare screenshots

This means you can automate login steps, set up UI states consistently, and even extend your CI pipeline with visual testing. Unlike manual hot reload tweaks or hardcoding start screens, Spix provides an external, scriptable solution without altering your application logic.

Setting up Spix in Your Project

Getting Spix integrated requires a few straightforward steps:

1. Add Spix as a dependency

Typically done via a Git submodule into your project’s third-party folder.

git submodule add 3rdparty/spix git@github.com:faaxm/spix.git

2. Register Spix in CMake

Update your CMakeLists.txt with a find_package(Spix REQUIRED) call.
Because of CMake quirks, you may also need to manually specify the path to Spix’s CMake modules.

LIST(APPEND CMAKE_MODULE_PATH /home/christoph/KDAB/spix/cmake/modules)
find_package(Spix REQUIRED)

3. Link against Spix

Add Spix to your target_link_libraries call.

target_link_libraries(myApp
  PRIVATE Qt6::Core
          Qt6::Quick 
          Qt6::SerialPort 
          Spix::Spix
)

4. Initialize Spix in your application

Include Spix headers in main.cpp.
Add some lines of boilerplate code:
- Include the 2 Spix Headers (AnyRPCServer for Communication and QtQmlBot)
- Start the Spix RPC server.
- Create a Spix::QtQmlBot.
- Run the test server on a specified port (e.g. 9000).

#include <Spix/AnyRpcServer.h>
#include <Spix/QtQmlBot.h>
[...]

//Start the actual Runner/Server
spix::AnyRpcServer server;
auto bot = new spix::QtQmlBot();
bot->runTestServer(server);

At this point, your application is "Spix-enabled". You can verify this by checking for the open port (e.g. localhost:9000).

Spix can be a Security Risk: Make sure to not expose Spix in any production environment, maybe only enable it for your Debug-builds.

Where Spix Shines

Once the setup is done, Spix can be used to automate repetitive tasks. Let’s look at two particularly useful examples:

1. Automating Logins with a Python Script

Instead of typing your credentials and clicking "Login" manually, you can write a simple Python script that:

Connects to the Spix server on localhost:9000
Inputs text into the userField and passwordField
Clicks the "Login" button (Items marked with "Quotes" are literal That-Specific-Text-Identifiers for Spix)

import xmlrpc.client

session = xmlrpc.client.ServerProxy('http://localhost:9000')

session.inputText('mainWindow/userField', 'christoph')
session.inputText('mainWindow/passwordField', 'secret') 
session.mouseClick('mainWindow/"Login"')

When executed, this script takes care of the entire login flow - no typing, no clicking, no wasted time. Better yet, you can check the script into your repository, so your whole team can reuse it.

For Development, Integration in Qt-Creator can be achieved with a Custom startup executable, that also starts this python script.

In a CI environment, this approach is particularly powerful, since you can ensure every test run starts from a clean state without relying on manual navigation.

2. Screenshot Comparison

Beyond input automation, Spix also supports taking screenshots. Combined with Python libraries like OpenCV or scikit-image, this opens up interesting possibilities for testing.

Example 1: Full-screen comparison

Take a screenshot of the main window and store it first:

import xmlrpc.client

session = xmlrpc.client.ServerProxy('http://localhost:9000')

[...]
session.takeScreenshot('mainWindow', '/tmp/screenshot.png')k

Now we can compare it with a reference image:

from skimage import io
from skimage.metrics import structural_similarity as ssim

screenshot1 = io.imread('/tmp/reference.png', as_gray=True)
screenshot2 = io.imread('/tmp/screenshot.png', as_gray=True)

ssim_index = ssim(screenshot1, screenshot2, data_range=screenshot1.max() - screenshot1.min())

threshold = 0.95

if ssim_index == 1.0: 
    print("The screenshots are a perfect match")
elif ssim_index >= threshold:
    print("The screenshots are similar, similarity: " + str(ssim_index * 100) + "%")
else:
    print("The screenshots are not similar at all, similarity: " + str(ssim_index * 100) + "%")

This is useful for catching unexpected regressions in visual layout.

Example 2: Finding differences in the same UI

Use OpenCV to highlight pixel-level differences between two screenshots—for instance, missing or misaligned elements:

import cv2

image1 = cv2.imread('/tmp/reference.png')
image2 = cv2.imread('/tmp/screenshot.png')

diff = cv2.absdiff(image1, image2)

# Convert the difference image to grayscale
gray = cv2.cvtColor(diff, cv2.COLOR_BGR2GRAY)

# Threshold the grayscale image to get a binary image
_, thresh = cv2.threshold(gray, 30, 255, cv2.THRESH_BINARY)

contours, _ = cv2.findContours(thresh, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE)
cv2.drawContours(image1, contours, -1, (0, 0, 255), 2)

cv2.imshow('Difference Image', image1)
cv2.waitKey(0)

This form of visual regression testing can be integrated into your CI system. If the UI changes unintentionally, Spix can detect it and trigger an alert.

Defective Image

The script marked the defective parts of the image compared to the should-be image.

Recap

Spix is not a full-blown GUI testing framework like Squish, but it fills a useful niche for embedded developers who want to:

Save time on repetitive input (like logins).
Share reproducible setup scripts with colleagues.
Perform lightweight visual regression testing in CI.
Interact with their applications on embedded devices remotely.

While there are limitations (e.g. manual wait times, lack of deep synchronization with UI states), Spix provides a powerful and flexible way to automate everyday development tasks - without having to alter your application logic.

If you’re tired of clicking the same buttons all day, give Spix a try. It might just save you hours of time and frustration in your embedded development workflow.

The post Automating Repetitive GUI Interactions in Embedded Development with Spix appeared first on KDAB.

AI Coding with Qt: Qt AI Assistant for Qt Creator

Jan Marker — Wed, 20 Aug 2025 06:38:08 GMT

AI Coding with Qt: Qt AI Assistant for Qt Creator

The integration of artificial intelligence into software development environments has rapidly evolved, and Qt Creator is no exception. With the introduction of the Qt AI Assistant by Qt Company, developers working with Qt Creator now have access to AI models through the IDE. This post provides an introduction to the Qt Creator plugin.

This is part 1 of an ongoing series about AI coding with Qt.

What is Qt AI Assistant?

Qt AI Assistant is a commercial plugin for Qt Creator to bring current AI models to the IDE. Features provided by the plugin include

Code completion for multiple languages (QML, C++, Python, Bash, etc.)
Contextual chat with your codebase, enabling explanations, code generation and code review
Automated test case generation, particularly tailored for QML and Qt-specific workflows
Model choice based on languages (QML vs other languages) and task (chat vs code completion)

This is a step up from the existing GitHub Copilot support in Qt Creator that was focused on code completion only.

Completing Qt AI Assistant is a publicly available set of models by Qt Group. The models are based on CodeLlama and are fine-tuned for usage with Qt 6 QML. They are not included with the plugin but need to be set up manually using Ollama.

Setting Up Qt AI Assistant

The setup process for Qt AI Assistant is more involved than some other AI coding tools. The plugin is currently available as part of the commercial Qt distribution. Installation requires enabling the appropriate extension repository within Qt Creator and activating the plugin. Once installed, configuration is necessary to connect the plugin to a large language model (LLM) provider.

Supported LLMs include OpenAI (ChatGPT), Anthropic (Claude), Google (Gemini), and self-hosted models via Ollama. For OpenAI integration, developers must use the OpenAI developer platform to generate an API key, which is different from having an account for ChatGPT. This API key is then entered into the plugin’s settings within Qt Creator. Other models require similar setup using URLs and credentials, depending on the provider or the self-hosting method.

More information is in this video linked at the bottom of this blog post.

Features in Practice

Code Completion and Chat

The plugin distinguishes between code completion suggestions as you type and prompt-based interactions, such as asking for code explanations or generating new code. For QML, a specialized Code Llama 13B QML model can be used. For other languages general purpose models are employed.

The chat interface allows developers to highlight code and request explanations or modifications. For example, selecting a block of QML or C++ and asking the assistant to "explain the selected code" yields a detailed, context-aware explanation.

Test Case Generation

A notable feature is the ability to generate test cases from selected QML code. While the generated tests may require manual refinement, this automation can accelerate the initial setup of unit tests and reduce repetitive work. The plugin’s approach is to copy relevant code into the test, which may not always result in optimal reuse, but provides a useful starting point.

Model Choice

Developers can choose between different LLMs to use for the chat and review vs the code completion scenario. For QML model choice is separate, and offers including the fine-tuned models provided by Qt Company. This flexibility extends to hosting options, supporting both cloud and local deployments, depending on organizational needs and privacy considerations.

Further Resources

For a detailed walkthrough and live demonstrations, watch the following episodes of "The Curious Developer" series:

Additionally, the official Qt AI Assistant product page provides up-to-date information on features and availability: https://www.qt.io/product/ai-assistant.

Outlook

Future posts in this series will consider alternative coding tools useful for Qt and will bring the newest developments of the tools we mention here.

The post AI Coding with Qt: Qt AI Assistant for Qt Creator appeared first on KDAB.

Using the Qt Logger in Rust with CXX-Qt

Fri, 08 Aug 2025 07:29:00 GMT

Using the Qt Logger in Rust with CXX-Qt

For projects incorporating Rust and Qt, a minor but important problem can arise: too many sources of log messages. In the usual case, one of these is from Rust (and crate dependencies) and another is from Qt. Our Rust and Qt solution, CXX-Qt, exposes a new API to help with this in the upcoming 0.8.0 release.

There are several benefits to ensuring your log messages go through one logger. It makes it easier to redirect said messages into a file, there's less configuration required for end users, and it makes consistent formatting easier.

Qt has its own logging infrastructure, and their suggested way to print messages in Qt applications. It has a category system, rules for filtering which messages you want to see, custom formatting and so on. Applications like GammaRay can also display messages from Qt, and configure which categories are emitted.

One of the more popular logging libraries in Rust is called tracing, and we're going to show how you can redirect messages from it to the Qt logger. The integration can work for any other logging crate too, including your own custom solution.

Getting started

Before we start splicing the two log streams, let's quickly go over sending a Qt log message in Rust. Assuming you already have a CXX-Qt application (and if you don't, you can follow our book, construct a message log context with QMessageLogContext:

let file = CString::new("main.rs").unwrap();  
let function = CString::new("main").unwrap();  
let category = CString::new("lib").unwrap();  
  
let context = QMessageLogContext::new(&file, 0, &function, &category);

You can specify the filename, the line number, the function name and even a category. We have to use CString here because QMessageLogContext in C++ uses const char*, not QString.

Note that there isn't a way to get the name of the currently calling function out of the box in Rust, but there are alternative solutions if you want that information.

Now that we have a context, we can send a message to the Qt logger. We can do this using the unfortunately undocumented qt_message_output function. This sends a message to the currently installed message handler.

Note that CXX-Qt currently doesn't have Rust bindings to install a custom one.

The default message handler goes to the standard output and error streams. This function takes a QtMsgType, the context we just created, and a QString message:

qt_message_output(  
    QtMsgType::QtInfoMsg,  
    &context,  
    &QString::from("This is an informational message..."),  
);

And voilà:

lib: This is an informational message...

But that looks pretty plain, and we can't see any of our context! Most information available in the Qt logger isn't shown by default, but we can modify it by using the QT_MESSAGE_PATTERN environment variable.

I used the comprehensive example given in the linked documentation, but it's useful for showcasing the context:

export QT_MESSAGE_PATTERN="[%{time yyyyMMdd h:mm:ss.zzz ttt} %{if-debug}D%{endif}%{if-info}I%{endif}%{if-warning}W%{endif}%{if-critical}C%{endif}%{if-fatal}F%{endif}] %{file}:%{line} - %{message}"

[20250314 8:56:45.033 EDT I] main.rs:0 - This is an informational message...

Now that we have sent our first Qt log message from Rust, let's up the ante and integrate the tracing crate.

Integrating with Tracing

To redirect events from tracing, we have to add a subscriber that forwards events to Qt. This basically means anything that uses tracing (e.g. your application, another crate) will be picked up.

As a side effect of tracing's flexibility, we also have to create our own Visitor. This is necessary because tracing records structured data, and we need to flatten said data to a string.

use std::fmt::Write; // needed for write_fmt

struct StringVisitor<'a> {
    string: &'a mut String,
}

impl tracing::field::Visit for StringVisitor<'_> {
    fn record_debug(&mut self, field: &tracing::field::Field, value: &dyn std::fmt::Debug) {
        write!(self.string, "{} = {:?} ", field.name(), value).unwrap();
    }
}

And now for the custom layer that will catch the events, and send them to Qt:

pub struct QtSubscriber {}

impl<S> tracing_subscriber::Layer<S> for QtSubscriber
    where
        S: tracing::Subscriber,
{
    fn on_event(
        &self,
        event: &tracing::Event<'_>,
        _ctx: tracing_subscriber::layer::Context<'_, S>,
    ) {
        let mut buffer: String = String::new();
        let mut visitor = StringVisitor {
            string: &mut buffer
        };
        event.record(&mut visitor);

        let msg_type = match *event.metadata().level() {
            tracing::Level::ERROR => QtMsgType::QtCriticalMsg,
            tracing::Level::WARN => QtMsgType::QtWarningMsg,
            tracing::Level::INFO => QtMsgType::QtInfoMsg,
            tracing::Level::DEBUG => QtMsgType::QtDebugMsg,
            tracing::Level::TRACE => QtMsgType::QtDebugMsg
        };

        let file = if let Some(file) = event.metadata().file() {
            CString::new(file).unwrap()
        } else {
            CString::default()
        };

        let line = if let Some(line) = event.metadata().line() {
            line as i32
        } else {
            0
        };
        
        let function = CString::default();  
        let category = CString::new("lib").unwrap();  

        let context = QMessageLogContext::new(&file, line, &function, &category);  

        qt_message_output(msg_type, &context, &QString::from(buffer));
    }
}

And finally, we have to register our new layer with the registry:

use tracing_subscriber::layer::SubscriberExt; // needed for with
use tracing_subscriber::util::SubscriberInitExt; // needed for init

tracing_subscriber::registry().with(QtSubscriber{}).init();

Afterwards, try sending a message using tracing::info! and see if it works:

tracing::info!("This is an informational message... from tracing!")

Using a more comprehensive QT_MESSAGE_PATTERN, you should get a log message from Qt. Note that "message" is written here, as that's the default field in tracing:

[20250320 10:41:40.617 EDT I] examples/cargo_without_cmake/src/main.rs:104 - message = This is an informational message...

These new bindings in CXX-Qt should be useful to application developers who want to adopt the best logging crates in Rust, while ensuring their messages are forwarded to Qt. If you want to redirect Qt log messages to Rust, CXX-Qt doesn't have a way to install custom message handlers yet.

See our KDABLabs repository for complete examples of the snippets shown here.

The post Using the Qt Logger in Rust with CXX-Qt appeared first on KDAB.

Display Widget Windows in Qt Quick Applications

Thu, 12 Jun 2025 08:28:00 GMT

Display Widget Windows in Qt Quick Applications

Developing an application for desktop or embedded platforms often means choosing between Qt Widgets and Qt Quick to develop the UI. There are pros and cons to each. Qt, being the flexible framework that it is, lets you combine these in various ways. How you should integrate these APIs will depend on what you're trying to achieve. In this entry I will show you how to display Qt Widget windows on an application written primarily using Qt Quick.

Qt Quick is great for software that puts emphasis on visual language. A graphics pipeline, based around the Qt Quick Scene Graph, will efficiently render your UI using the GPU. This means UI elements can be drawn, decorated, and animated efficiently as long as you pick the right tools (e.g. Shaders, Animators, and Qt's Shapes API instead of its implementation of HTML's Canvas).

From the Scene Graph also stem some of Quick's weaknesses. UI elements that in other applications would extend outside of the application's window, such as tool tips and the ComboBox control, can only be rendered inside of Qt Quick windows. When you see other app's tooltips and dropdowns extend beyond the window, those items are being rendered onto a separate windows; one without window decorations (a.k.a. borderless windows). Rendering everything on the same window helps ensure your app will be compatible with systems that can only display a single window at a time, such as Android and iOS, but it could result in wasted space if your app targets PC desktop environments.

An animation shows a small window with QML's and Widget's ComboBoxes opening for comparison purposes

QML ComboBox is confined to the Qt Quick window while the Widgets ComboBox extends beyond the window

Qt lets us combine Widgets and Quick in a few ways. The most common approach is to embed a Qt Quick view into your Widgets app, using QQuickWidget. That approach is fitting for applications that primarily use Widgets. Another option is to render Widgets inside a Qt Quick component, by rendering it through a QQuickPaintedItem. However, this component will be limited to the same window confines as the rest of the items in your Quick window and it won't benefit from Scene Graph rendering optimizations, meaning you get the worst of both worlds.

A third solution is to open widget windows from your Qt Quick apps. This has none of the aforementioned drawbacks, however, the approach has a couple of drawback of its own. First, the app would need to be run from a multi-window per screen capable environment. Second, widget windows are not parentable to Qt Quick windows; meaning certain window z-stack related features, such as setting window modality to Qt::WindowModal, won't have effect on the triggering window when a Widget is opened from Qt Quick. You can work around that by setting modality to Qt::ApplicationModal instead, if you're okay with blocking all other windows for modality.

Displaying Widget windows in Qt Quick applications has been useful to me in the past, and is something I haven't seen documented anywhere, hence this tutorial.

Architecture Big Picture

Displaying a Qt Widget window from Qt Quick is simpler than it seems. You'll need two classes:

The class that represents the widget window.
A class to interface from QML, that hosts and instantiates the window.

You might be tempted to forgo the interface class and instantiate the widget directly. However, this would result in a crash. We'll display the widget window by running Widget::show from the interface class.

Update `CMakeLists.txt`

In addition to those classes, you'll also need to make sure that your app links to both Qt::Quick and Qt::Widgets libraries. Here's what that looks like for a CMake project

// Locate libraries
find_package(Qt6 6.5 REQUIRED COMPONENTS
    Quick
    Widgets)

// Link build target to libraries
target_link_libraries(${TARGET_NAME} PRIVATE
    Qt6::Quick
    Qt6::Widgets)

// Replace ${TARGET_NAME} with the name of your target executable

Update `main.cpp`

In addition to that, in main.cpp you'll need to use QApplication in place of QGuiApplication.

QApplication app(argc, argv);

The Interface Layer

Prepare the interface layer as you would any C++ based Quick component. By this I mean: derive from QObject, and use the Q_OBJECT and QML_ELEMENT macros to make your class available from QML.

// widgetFormHandler.h
#pragma once
class WidgetFormHandler : public QObject
{
    Q_OBJECT
    QML_ELEMENT

public:
    explicit WidgetFormHandler(QObject *parent = nullptr);
};

// widgetFormHandler.cpp

WidgetFormHandler::WidgetFormHandler(QObject *parent)
    : QObject(parent)
{
}

Instantiating the Widgets Window

// widgetFormHandler.h
#pragma once
class WidgetsForm;
class WidgetFormHandler : public QObject
{
    Q_OBJECT
    QML_ELEMENT

public:
    explicit WidgetFormHandler(QObject *parent = nullptr);
~WidgetFormHandler();

private:
    std::unique_ptr<WidgetsForm> m_window;
}

Use std::make_unique in the constructor to initialize the unique pointer to m_window.

Define the instantiating class' destructor to ensure the pointers are de-alocated, thus preventing memory leaks. If you stick to using smart pointers, C++ will do all the work for you; simply use the default destructor, like I do here. Make sure to define it outside of the class' header; some compilers have trouble dealing with the destructor when it's defined inside the header.

// widgetFormHandler.cpp
#include "widgetFormHandler.h"

WidgetFormHandler::WidgetFormHandler(QObject *parent)
    : QObject(parent)
    , m_window(std::make_unique<WidgetsForm>())
{
    // ...
}

WidgetFormHandler::~WidgetFormHandler() = default;

Make Properties Available to QML

Now we want to make properties from the widget available in QML. How we do this will depend on the property and on whether we will manipulate the property's value from both directions or only from one side only and update on the other.

Let's look at a bi-directional example in which we add the ability to control the visible state of the widget window from QML. We'll add a property called "visible" to the C++ interface so that it matches the visible that we get from Qt Quick windows in QML. Declare the property using Q_PROPERTY. Use READ and WRITE functions to control the window's state.

Here's what that would look like:

// widgetFormHandler.h
#pragma once
class WidgetsForm;

class WidgetFormHandler : public QObject
{
    Q_OBJECT
    QML_ELEMENT
    Q_PROPERTY(bool visible READ isVisible WRITE setVisible NOTIFY visibleChanged)

public:
    explicit WidgetFormHandler(QObject *parent = nullptr);    
~WidgetFormHandler();
    const bool isVisible();    
    void setVisible(bool);

signals:
    void visibleChanged();

private:
    std::unique_ptr<WidgetsForm> m_window;
};

// widgetFormHandler.cpp
#include "widgetFormHandler.h"

#include "widgetForm.h"

WidgetFormHandler::WidgetFormHandler(QObject *parent)
    : QObject(parent)
    , m_window(std::make_unique<WidgetsForm>())
{
    // Hide window by default
    m_window->setVisible(false);
}
WidgetFormHandler::~WidgetFormHandler() = default;
const bool WidgetFormHandler::isVisible()
{
    return m_window->isVisible();
}
void WidgetFormHandler::setVisible(bool visible)
{
    m_window->setVisible(visible);
    emit visibleChanged();
}

To make this bi-directional, set NOTIFY to a signal that allows the property to be updated in QML after it being emitted and emit the signal where applicable. We emit it from setVisible in this class, however if QWidget had a signal that emitted when its visible state changed, I would also make a connection between that signal and that of our handler’s visibleChanged. However, that isn’t the case, so we have to make sure to emit it ourselves.

Make Signals Available to QML

Develop the widget window as you would any other widget. If you use UI forms, go to the header file and create a signal for each action that you wish to relay over to QML.

In this example we'll relay a button press from the UI file, so we'll create a button named pushButton in our ui file:

Qt Designer shows UI file with a button named pushButton, in camel case.

Now add a buttonClicked signal to our header:

// widgetsForm.h
#pragma once
#include <QWidget>

namespace Ui
{
    class WidgetsForm;
}

class WidgetsForm : public QWidget
{
    Q_OBJECT
public:
    explicit WidgetsForm(QWidget *parent = nullptr);
    ~WidgetsForm();
signals:
    void buttonClicked();
    // Signal to expose button click from Widgets window
private:
    std::unique_ptr<Ui::WidgetsForm> ui;
};

Once again, we use a unique pointer, this time to hold the ui object. This is better than what Qt Creator templates give us because it means C++ handles the memory management for us and we can avoid the need for a delete statement in the destructor.

In the window's constructor, we make a connection between the UI's button's signal and the one that we've created to relay the signal for exposure.

// widgetsForm.cpp
#include "widgetsform.h"
#include "ui_widgetsform.h"

WidgetsForm::WidgetsForm(QWidget *parent)
    : QWidget(parent)
    , ui(std::make_unique<Ui::WidgetsForm>())
{
    ui->setupUi(this);
    // Expose click
    connect(ui->pushButton, &QPushButton::clicked, this, &WidgetsForm::buttonClicked);
}

WidgetsForm::~WidgetsForm() = default;

Before we connect the exposed signal to the QML interface, we need another signal on the interface to expose our event over to QML. Here I add qmlSignalEmitter signal for that purpose:

// widgetFormHandler.h
[..]
signals:
    void visibleChanged();
    void qmlSignalEmitter();  // Signal to relay button press to QML
[..]

To complete all the connections, go to the interface layer’s constructor and make a connection between your window class’ signal and that of the interface layer. This would look as follows:

// widgetFormHandler.cpp
[..]
WidgetFormHandler::WidgetFormHandler(QObject *parent)
    : QObject(parent)
    , m_window(std::make_unique<WidgetsForm>())
{
    QObject::connect(m_window, &WidgetsForm::buttonClicked, this,
    &WidgetFormHandler::qmlSignalEmitter);
}
[..]

By connecting one emitter to another emitter we keep each classes' concerns separate and reduce the amount of boilerplate code, making our code easier to maintain.

Over at the QML, we connect to qmlSignalEmitter using the on prefix. It would look like this:

import NameOfAppQmlModule  // Should match qt_add_qml_module's URI on CMake

WidgetFormHandler {
    id: fontWidgetsForm

    visible: true  // Make the Widgets window visible from QML

    onQmlSignalEmitter: () => {
        console.log("Button pressed in widgets")  // Log QPushButton's click event from QML
    }
}

Final Product

I've prepared a demo app where you can see this technique in action. The demo displays text that bounces around the screen like an old DVD player's logo would. You change the text and font through two identical forms, one implemented in QML and the other done in Widgets. The code presented in this tutorial comes from that demo app.

Example code: https://github.com/KDABLabs/kdabtv/tree/master/Blog-projects/Widget-window-in-Qt-Quick-app

The moving text should work on all desktop systems except for Wayland sessions on Linux. That is because I'm animating the window's absolute position (which is restricted in Wayland for security reasons) rather than the contents inside a window. This has the benefit of not obstructing other applications, since the moving window that contains the text would capture mouse inputs if clicked, preventing those from reaching the application behind it.

Real World Use Case

The first time I employed this technique was in my FOSS project, QPrompt. I use it there to provide a custom font dialog that doubles as a text preview. Having a custom dialog gives me full control over formatting options presented to users, and for this app we only needed a preview for large text and a combo box to choose among system fonts. QPrompt is also open source, you can find the source code relevant to this technique here: https://github.com/Cuperino/QPrompt-Teleprompter/blob/main/src/systemfontchooserdialog.h

Thank you for reading. I hope you’ll find this useful. A big thank you to David Faure for suggesting the use of C++ unique pointers as well as reviewing the code along with Renato and my team.

If there are other techniques that you’d like for us to try or showcase, let us know.

The post Display Widget Windows in Qt Quick Applications appeared first on KDAB.

Integrate QML Window's Background with the System's Color Palette

Thu, 24 Apr 2025 06:43:49 GMT

Integrate QML Window's Background with the System's Color Palette

As a person who enjoys responsive designs, I like to resize apps and see how quickly the UI updates after the resize. If you're making an app with Qt Quick, you'll sometimes find that, as the window size increases, the UI will lag behind for one or more frames, revealing a white background on two of the window's edges, that usually looks out of place on desktop applications.

Thumbnail: A window with a white border where there should be a background color.

Why is the color background revealed when the window size is increased?

This issue stems from the fact that Qt Quick windows will render a background color, white by default, before the position of elements is updated by the scene graph, which lags at least one frame behind the resize because it uses a frame buffer. If the default background is white, that means the QML window itself is not aware of your application's theme and that is intentional; after all, only desktop apps need to be aware of the background color used by native applications.

Qt Quick Controls, however, are theme aware, and that may include your platform's theme. This is why, when you make an app for Windows, if you set a Label against the application's default white background, it will look just fine. But when that app is moved to macOS or a Linux distribution with a dark theme, the label's text will be drawn with a light color to match that theme, and that will make it nearly impossible to read against the default white background.

One solution for that issue is to place these components against a control that extends through a large area, such as a Pane. Qt Quick Controls' theme awareness will ensure the right background color is used. However, controls are only drawn within the window, so when the window is resized, its true background color will seep through -- and that's the issue with which we're concerned. The correct solution is to set the window's background to the system's or the theme's background color, which will make the frame buffer's lag far less noticeable during resizing.

How to Make Qt Quick Window Backgrounds Aware of Your System's Theme

Setting a background color is as simple as assigning a value to the "color" property of the window, like so:

Window {
    color: "lightblue"
}

To have it match the background color of native apps, use QML's SystemPallete type, as follows:

import QtQuick
Window {
    color: systemPalette.window
    SystemPalette {
        id: systemPalette
    }
}

Here you can find the various default styles used by Qt Quick for each supported platform. By making use of SystemPalette, the appropriate background color for the current platform will be chosen.

It is important to note that, using SystemPalette, the background color will be chosen based on the current platform and not on which QML style has actually been applied, which may differ if your app makes use of a fixed style for all platforms.

Animation of a window resizing, letting the white background seep through a corner.

Animation of a window resizing. The background color is consistent with the theme at all times.

Platform Style vs. Fixed Style

As an alternative to following the platform's theme, you could provide a uniform experience for all platforms by enforcing one style for all. There are minor performance advantages to having a fixed style for all systems, but these only tend to matter on low-end embedded hardware, where every cycle counts. There you could use Compile-Time Style Selection, so the QML compiler knows which style is in use and can generate C++ code for bindings.

If you are creating a desktop application, your theming choice should be based, not on performance, but on the level of system integration and the user experience you wish to provide. A photography application might benefit from having a dark mode at all times so the picture colors can pop. An e-mail client, on the other hand, might do better integrating with the system's theme or allowing users to choose between a light theme and a dark theme. Light backgrounds generally provide better contrast, which makes them a good default choice for emails. However, users may prefer the system theme or a dark theme, if it's easier on their eyes.

A window from one OS, with a light theme. Its contents can be read just fine.

A window from a different OS, with a dark theme. Some of it contents cannot be read due to a lack of contrast.

Crafting Seamless and Theme-Aware Qt Quick Applications

By thoughtfully managing your Qt Quick application's window background color, you can significantly improve its responsiveness and aesthetic integration with the host platform. Whether you opt to align with the system's theme using SystemPalette or enforce a fixed style for uniformity, your choice should reflect the needs of your application and its users. Balancing system integration, performance, and user experience ensures your app not only looks great across platforms but also feels natural to use, providing a polished and professional result. With these tools and insights, you can create dynamic, theme-aware applications that stand out in usability and design.

The post Integrate QML Window's Background with the System's Color Palette appeared first on KDAB.

Model/View Drag and Drop in Qt - Part 3

David Faure — Thu, 03 Apr 2025 08:43:00 GMT

Model/View Drag and Drop in Qt - Part 3

In this third blog post of the Model/View Drag and Drop series (part 1 and part 2), the idea is to implement dropping onto items, rather than in between items. QListWidget and QTableWidget have out of the box support for replacing the value of existing items when doing that, but there aren't many use cases for that. What is much more common is to associate a custom semantic to such a drop. For instance, the examples detailed below show email folders and their contents, and dropping an email onto another folder will move (or copy) the email into that folder.

Step 1

Initial state, the email is in the inbox

Step 2

Dragging the email onto the Customers folder

Step 3

Dropping the email

Step 4

The email is now in the customers folder

With Model/View separation

Example code can be found here for flat models and here for tree models.

Setting up the view on the drag side

☑ Call view->setDragDropMode(QAbstractItemView::DragOnly)
unless of course the same view should also support drops. In our example, only emails can be dragged, and only folders allow drops, so the drag and drop sides are distinct.

☑ Call view->setDragDropOverwriteMode(...)
true if moving should clear cells, false if moving should remove rows.
Note that the default is true for QTableView and false for QListView and QTreeView. In our example, we want to remove emails that have been moved elsewhere, so false is correct.

☑ Call view->setDefaultDropAction(Qt::MoveAction) so that the drag defaults to a move and not a copy, adjust as needed

Setting up the model on the drag side

To implement dragging items out of a model, you need to implement the following -- this is very similar to the section of the same name in the previous blog post, obviously:

class EmailsModel : public QAbstractTableModel
{
    ~~~
    Qt::ItemFlags flags(const QModelIndex &index) const override
    {
        if (!index.isValid())
            return {};
        return Qt::ItemIsEnabled | Qt::ItemIsSelectable | Qt::ItemIsDragEnabled;
    }

    // the default is "copy only", change it
    Qt::DropActions supportedDragActions() const override { return Qt::MoveAction | Qt::CopyAction; }

    QMimeData *mimeData(const QModelIndexList &indexes) const override;

    bool removeRows(int position, int rows, const QModelIndex &parent) override;

☑ Reimplement flags() to add Qt::ItemIsDragEnabled in the case of a valid index

☑ Reimplement supportedDragActions() to return Qt::MoveAction | Qt::CopyAction or whichever you want to support (the default is CopyAction only).

☑ Reimplement mimeData() to serialize the complete data for the dragged items. If the views are always in the same process, you can get away with serializing only node pointers (if you have that) and application PID (to refuse dropping onto another process). See the previous part of this blog series for more details.

☑ Reimplement removeRows(), it will be called after a successful drop with MoveAction. An example implementation looks like this:

bool EmailsModel::removeRows(int position, int rows, const QModelIndex &parent)
{
    beginRemoveRows(parent, position, position + rows - 1);
    for (int row = 0; row < rows; ++row) {
        m_emailFolder->emails.removeAt(position);
    }
    endRemoveRows();
    return true;
}

Setting up the view on the drop side

☑ Call view->setDragDropMode(QAbstractItemView::DropOnly) unless of course it supports dragging too. In our example, we can drop onto email folders but we cannot reorganize the folders, so DropOnly is correct.

Setting up the model on the drop side

To implement dropping items into a model's existing items, you need to do the following:

class FoldersModel : public QAbstractTableModel
{
    ~~~    
    Qt::ItemFlags flags(const QModelIndex &index) const override
    {
        CHECK_flags(index);
        if (!index.isValid())
            return {}; // do not allow dropping between items
        if (index.column() > 0)
            return Qt::ItemIsEnabled | Qt::ItemIsSelectable; // don't drop on other columns
        return Qt::ItemIsEnabled | Qt::ItemIsSelectable | Qt::ItemIsDropEnabled;
    }

    // the default is "copy only", change it
    Qt::DropActions supportedDropActions() const override { return Qt::MoveAction | Qt::CopyAction; }
  
    QStringList mimeTypes() const override { return {QString::fromLatin1(s_emailsMimeType)}; }
  
    bool dropMimeData(const QMimeData *mimeData, Qt::DropAction action, int row, int column, const QModelIndex &parent) override;
};

☑ Reimplement flags()
For a valid index (and only in that case), add Qt::ItemIsDropEnabled. As you can see, you can also restrict drops to column 0, which can be more sensible when using QTreeView (the user should drop onto the folder name, not onto the folder size).

☑ Reimplement supportedDropActions() to return Qt::MoveAction | Qt::CopyAction or whichever you want to support (the default is CopyAction only).

☑ Reimplement mimeTypes() - the list should include the MIME type used by the drag model.

☑ Reimplement dropMimeData()
to deserialize the data and handle the drop.
This could mean calling setData() to replace item contents, or anything else that should happen on a drop: in the email example, this is where we copy or move the email into the destination folder. Once you're done, return true, so that the drag side then deletes the dragged rows by calling removeRows() on its model.

bool FoldersModel::dropMimeData(const QMimeData *mimeData, Qt::DropAction action, int row, int column, const QModelIndex &parent)
{
    ~~~  // safety checks, see full example code

    EmailFolder *destFolder = folderForIndex(parent);

    const QByteArray encodedData = mimeData->data(s_emailsMimeType);
    QDataStream stream(encodedData);
    ~~~ // code to detect and reject dropping onto the folder currently holding those emails

    while (!stream.atEnd()) {
        QString email;
        stream >> email;
        destFolder->emails.append(email);
    }
    emit dataChanged(parent, parent); // update count

    return true; // let the view handle deletion on the source side by calling removeRows there
}

Using item widgets

Example code:

On the "drag" side

☑ Call widget->setDragDropMode(QAbstractItemView::DragOnly) or DragDrop if it should support both

☑ Call widget->setDefaultDropAction(Qt::MoveAction) so that the drag defaults to a move and not a copy, adjust as needed

☑ Reimplement Widget::mimeData() to serialize the complete data for the dragged items. If the views are always in the same process, you can get away with serializing only item pointers and application PID (to refuse dropping onto another process). In our email folders example we also serialize the pointer to the source folder (where the emails come from) so that we can detect dropping onto the same folder (which should do nothing).

To serialize pointers in QDataStream, cast them to quintptr, see the example code for details.

On the "drop" side

☑ Call widget->setDragDropMode(QAbstractItemView::DropOnly) or DragDrop if it should support both

☑ Call widget->setDragDropOverwriteMode(true) for a minor improvement: no forbidden cursor when moving the drag between folders. Instead Qt only computes drop positions which are onto items, as we want here.

☑ Reimplement Widget::mimeTypes() and return the same name as the one used on the drag side's mimeData

☑ Reimplement Widget::dropMimeData() (note that the signature is different between QListWidget, QTableWidget and QTreeWidget) This is where you deserialize the data and handle the drop. In the email example, this is where we copy or move the email into the destination folder.

Make sure to do all of the following:

any necessary behind the scenes work (in our case, moving the actual email)
updating the UI (creating or deleting items as needed)

This is a case where proper model/view separation is actually much simpler.

Improvements to Qt

While writing and testing these code examples, I improved the following things in Qt, in addition to those listed in the previous blog posts:

QTBUG-2553 QTreeView with setAutoExpandDelay() collapses items while dragging over it, fixed in Qt 6.8.1

Conclusion

I hope you enjoyed this blog post series and learned a few things.

The post Model/View Drag and Drop in Qt - Part 3 appeared first on KDAB.

Model/View Drag and Drop in Qt - Part 2

David Faure — Mon, 10 Mar 2025 08:19:00 GMT

Model/View Drag and Drop in Qt - Part 2

In the previous blog, you learned all about moving items within a single view, to reorder them.

In part 2, we are still talking about moving items, and still about inserting them between existing items (never overwriting items) but this time the user can move items from one view to another. A typical use case is a list of available items on the left, and a list of selected items on the right (one concrete example would be to let the user customize which buttons should appear in a toolbar). This also often includes reordering items in the right-side list, the good news being that this comes for free (no extra code needed).

Moving a row between treeviews, step 1

Moving a row between treeviews, step 2

Moving a row between treeviews, step 3

With Model/View separation

Example code for flat models and example code for tree models.

Setting up the view on the drag side

To allow dragging items out of the view, make sure to do the following:

☑ Call view->setDragDropMode(QAbstractItemView::DragOnly) (or DragDrop if it should support both).

☑ Call view->setDragDropOverwriteMode(false) so that QTableView calls removeRows when moving rows, rather than just clearing their cells

☑ Call view->setDefaultDropAction(Qt::MoveAction) so it's a move and not a copy

Setting up the model on the drag side

To implement dragging items out of a model, you need to implement the following:

class CountryModel : public QAbstractTableModel
{
    ~~~
    Qt::ItemFlags flags(const QModelIndex &index) const override
    {
        if (!index.isValid())
            return {}; // depending on whether you want drops as well (next section)
        return Qt::ItemIsEnabled | Qt::ItemIsSelectable | Qt::ItemIsDragEnabled;
    }

    // the default is "return supportedDropActions()", let's be explicit
    Qt::DropActions supportedDragActions() const override { return Qt::MoveAction; }

    QMimeData *mimeData(const QModelIndexList &indexes) const override; // see below

    bool removeRows(int position, int rows, const QModelIndex &parent) override; // see below
};

More precisely, the check-list is the following:

☑ Reimplement flags() to add Qt::ItemIsDragEnabled in the case of a valid index

☑ Reimplement supportedDragActions() to return Qt::MoveAction

☑ Reimplement mimeData() to serialize the complete data for the dragged items. If the views are always in the same process, you can get away with serializing only node pointers (if you have that, e.g. for tree models) and application PID (to refuse dropping onto another process). Otherwise you can encode the actual data, like this:

QMimeData *CountryModel::mimeData(const QModelIndexList &indexes) const
{
    QByteArray encodedData;
    QDataStream stream(&encodedData, QIODevice::WriteOnly);
    for (const QModelIndex &index : indexes) {
        // This calls operator<<(QDataStream &stream, const CountryData &countryData), which you must implement
        stream << m_data.at(index.row());
    }

    QMimeData *mimeData = new QMimeData;
    mimeData->setData(s_mimeType, encodedData);
    return mimeData;
}

s_mimeType is the name of the type of data (make up a name, it usually starts with application/x-)

☑ Reimplement removeRows(), it will be called after a successful drop. For instance, if your data is in a vector called m_data, the implementation would look like this:

bool CountryModel::removeRows(int position, int rows, const QModelIndex &parent)
{
    beginRemoveRows(parent, position, position + rows - 1);
    for (int row = 0; row < rows; ++row)
        m_data.removeAt(position);
    endRemoveRows();
    return true;
}

Setting up the view on the drop side

☑ Call view->setDragDropMode(QAbstractItemView::DragDrop) (already done if both views should support dragging and dropping)

Setting up the model on the drop side

To implement dropping items into a model (between existing items), you need to implement the following:

class DropModel : public QAbstractTableModel
{
    ~~~
    Qt::ItemFlags flags(const QModelIndex &index) const override
    {
        if (!index.isValid())
            return Qt::ItemIsDropEnabled;
        return Qt::ItemIsEnabled | Qt::ItemIsSelectable; // and optionally Qt::ItemIsDragEnabled (previous section)
    }

    // the default is "copy only", change it
    Qt::DropActions supportedDropActions() const override { return Qt::MoveAction; }

    QStringList mimeTypes() const override { return {QString::fromLatin1(s_mimeType)}; }

    bool dropMimeData(const QMimeData *mimeData, Qt::DropAction action, 
                      int row, int column, const QModelIndex &parent) override; // see below
};

☑ Reimplement supportedDropActions() to return Qt::MoveAction

☑ Reimplement flags()
For a valid index, make sure Qt::ItemIsDropEnabled is NOT set (except for tree models where we need to drop onto items in order to insert a first child).
For the invalid index, add Qt::ItemIsDropEnabled, to allow dropping between items.

☑ Reimplement mimeTypes() and return the name of the MIME type used by the mimeData() function on the drag side.

☑ Reimplement dropMimeData()
to deserialize the data and insert new rows.
In the special case of in-process tree models, clone the dragged nodes.
In both cases, once you're done, return true, so that the drag side then deletes the dragged rows by calling removeRows() on its model.

bool DropModel::dropMimeData(const QMimeData *mimeData, Qt::DropAction action, int row, int column, const QModelIndex &parent)
{
    ~~~  // safety checks, see full example code

    if (row == -1) // drop into empty area = append
        row = rowCount(parent);

    // decode data
    const QByteArray encodedData = mimeData->data(s_mimeType);
    QDataStream stream(encodedData);
    QVector<CountryData> newCountries;
    while (!stream.atEnd()) {
        CountryData countryData;
        stream >> countryData;
        newCountries.append(countryData);
    }

    // insert new countries
    beginInsertRows(parent, row, row + newCountries.count() - 1);
    for (const CountryData &countryData : newCountries)
        m_data.insert(row++, countryData);
    endInsertRows();

    return true; // let the view handle deletion on the source side by calling removeRows there
}

Using item widgets

Example code can be found following this link.

For all kinds of widgets

On the "drag" side:

☑ Call widget->setDragDropMode(QAbstractItemView::DragOnly) or DragDrop if it should support both

☑ Call widget->setDefaultDropAction(Qt::MoveAction) so the drag starts as a move right away

On the "drop" side:

☑ Call widget->setDragDropMode(QAbstractItemView::DropOnly) or DragDrop if it should support both

☑ Reimplement supportedDropActions() to return only Qt::MoveAction

Additional requirements for QTableWidget

When using QTableWidget, in addition to the common steps above you need to:

On the "drag" side:

☑ Call item->setFlags(item->flags() & ~Qt::ItemIsDropEnabled); for each item, to disable dropping onto items.

☑ Call widget->setDragDropOverwriteMode(false) so that after a move the rows are removed rather than cleared

On the "drop" side:

☑ Call widget->setDragDropOverwriteMode(false) so that it inserts rows instead of replacing cells (the default is false for the other views anyway)

☑ Another problem is that the items created by a drop will automatically get the Qt::ItemIsDropEnabled flag, which you don't want. To solve this, use widget->setItemPrototype() with an item that has the right flags (see the example).

Additional requirements for QTreeWidget

When using QTreeWidget, you cannot disable dropping onto items (which creates a child of the item).

You could call item->setFlags(item->flags() & ~Qt::ItemIsDropEnabled); on your own items, but when QTreeWidget creates new items upon a drop, you cannot prevent them from having the flag Qt::ItemIsDropEnabled set. The prototype solution used above for QTableWidget doesn't exist for QTreeWidget.

This means, if you want to let the user build and reorganize an actual tree, you can use QTreeWidget. But if you just want a flat multi-column list, then you should use QTreeView (see previous section on model/view separation).

Addendum: Move/copy items between views

If the user should be able to choose between copying and moving items, follow the previous section and make the following changes.

With Model/View separation

On the "drag" side:

☑ Call view->setDefaultDropAction(...) to choose whether the default should be move or copy. The user can press Shift to force a move, and Ctrl to force a copy.

☑ Reimplement supportedDragActions() in the model to return Qt::MoveAction | Qt::CopyAction

On the "drop" side:

☑ Reimplement supportedDropActions() in the model to return Qt::MoveAction | Qt::CopyAction

The good news is that there's nothing else to do.

Using item widgets

On the "drag" side:

☑ Call widget->setDefaultDropAction(...) to choose whether the default should be move or copy. The user can press Shift to force a move, and Ctrl to force a copy.

Until Qt 6.10 there was no setSupportedDragActions() method in the item widget classes (that was QTBUG-87465, I implemented it for 6.10). Fortunately the default behavior is to use what supportedDropActions() returns so if you just want move and copy in both, reimplementing supportedDropActions() is enough.

On the "drop" side:

☑ Reimplement supportedDropActions() in the item widget class to return Qt::MoveAction | Qt::CopyAction

The good news is that there's nothing else to do.

Improvements to Qt

While writing and testing these code examples, I improved the following things in Qt:

QTBUG-1387 "Drag and drop multiple columns with item views. Dragging a row and dropping it in a column > 0 creates multiple rows.", fixed in 6.8.1
QTBUG-36831 "Drop indicator painted as single pixel when not shown" fixed in 6.8.1
QTBUG-87465 ItemWidgets: add supportedDragActions()/setSupportedDragActions(), implemented in 6.10

Conclusion

In the next blog post of this series, you will learn how to move (or copy) onto existing items, rather than between them.

The post Model/View Drag and Drop in Qt - Part 2 appeared first on KDAB.

Model/View Drag and Drop in Qt - Part 1

David Faure — Thu, 06 Feb 2025 08:07:00 GMT

Model/View Drag and Drop in Qt - Part 1

This blog series is all about implementing drag-and-drop in the Qt model/view framework. In addition to complete code examples, you'll find checklists that you can go through to make sure that you did not forget anything in your own implementation, when something isn't working as expected.

At first, we are going to look at Drag and Drop within a single view, to change the order of the items. The view can be a list, a table or a tree, there are very little differences in what you have to do.

Moving a row in a tableview, step 1

Moving a row in a tableview, step 2

Moving a row in a tableview, step 3

The main question, however, is whether you are using QListView/QTableView/QTreeView on top of a custom item model, or QListWidget/QTableWidget/QTreeWidget with items in them. Let's explore each one in turn.

With Model/View separation

The code being discussed here is extracted from the example. That example features a flat model, while this example features a tree model. The checklist is the same for these two cases.

Setting up the view

☑ Call view->setDragDropMode(QAbstractItemView::InternalMove) to enable the mode where only moving within the same view is allowed

☑ When using QTableView, call view->setDragDropOverwriteMode(false) so that it inserts rows instead of replacing cells (the default is false for the other views anyway)

Adding drag-n-drop support to the model

Reorderable ListView

Reorderable TableView

For a model being used in QListView or QTableView, all you need is something like this:

class CountryModel : public QAbstractTableModel
{
    ~~~
    Qt::ItemFlags flags(const QModelIndex &index) const override
    {
        if (!index.isValid())
            return Qt::ItemIsDropEnabled; // allow dropping between items
        return Qt::ItemIsEnabled | Qt::ItemIsSelectable | Qt::ItemIsDragEnabled;
    }

    // the default is "copy only", change it
    Qt::DropActions supportedDropActions() const override { return Qt::MoveAction; }

    // the default is "return supportedDropActions()", let's be explicit
    Qt::DropActions supportedDragActions() const override { return Qt::MoveAction; }

    QStringList mimeTypes() const override { return {QString::fromLatin1(s_mimeType)}; }

    bool moveRows(const QModelIndex &sourceParent, int sourceRow, int count, const QModelIndex &destinationParent, int destinationChild) override; // see below
};

The checklist for the changes you need to make in your model is therefore the following:

☑ Reimplement flags()
For a valid index, add Qt::ItemIsDragEnabled and make sure Qt::ItemIsDropEnabled is NOT set (except for tree models where we need to drop onto items in order to insert a first child). \

☑ Reimplement mimeTypes() and make up a name for the mimetype (usually starting with application/x-)

☑ Reimplement supportedDragActions() to return Qt::MoveAction

☑ Reimplement supportedDropActions() to return Qt::MoveAction

☑ Reimplement moveRows()

Note that this approach is only valid when using QListView or, assuming Qt >= 6.8.0, QTableView - see the following sections for details.

In a model that encapsulates a QVector called m_data, the implementation of moveRows can look like this:

bool CountryModel::moveRows(const QModelIndex &sourceParent, int sourceRow, int count, const QModelIndex &destinationParent, int destinationChild)
{
    if (!beginMoveRows(sourceParent, sourceRow, sourceRow + count - 1, destinationParent, destinationChild))
        return false; // invalid move, e.g. no-op (move row 2 to row 2 or to row 3)

    for (int i = 0; i < count; ++i) {
        m_data.move(sourceRow + i, destinationChild + (sourceRow > destinationChild ? 0 : -1));
    }

    endMoveRows();
    return true;
}

QTreeView does not call moveRows

Reorderable treeview

Reorderable treeview with a tree model

QTreeView does not (yet?) call moveRows in the model, so you need to:

☑ Reimplement mimeData() to encode row numbers for flat models, and node pointers for tree models

☑ Reimplement dropMimeData() to implement the move and return false (meaning: all done)

Note that this means a move is in fact an insertion and a deletion, so the selection isn't automatically updated to point to the moved row(s).

QTableView in Qt < 6.8.0

I implemented moving of rows in QTableView itself for Qt 6.8.0, so that moving rows in a table view is simpler to implement (one method instead of two), more efficient, and so that selection is updated. If you're not yet using Qt >= 6.8.0 then you'll have to reimplement mimeData() and dropMimeData() in your model, as per the previous section.

This concludes the section on how to implement a reorderable view using a separate model class.

Using item widgets

The alternative to model/view separation is the use of the item widgets (QListWidget, QTableWidget or QTreeWidget) which you populate directly by creating items.

Reorderable QListWidget

Reorderable QTableWidget

Reorderable QTreeWidget

Here's what you need to do to allow users to reorder those items.

Example code can be found following this link.

Reorderable QListWidget

☑ Call listWidget->setDragDropMode(QAbstractItemView::InternalMove) to enable the mode where only moving within the same view is allowed

For a QListWidget, this is all you need. That was easy!

Reorderable QTableWidget

When using QTableWidget:

☑ Call tableWidget->setDragDropMode(QAbstractItemView::InternalMove)

☑ Call tableWidget->setDragDropOverwriteMode(false) so that it inserts rows instead of replacing cells

☑ Call item->setFlags(item->flags() & ~Qt::ItemIsDropEnabled); on each item, to disable dropping onto items

Note: Before Qt 6.8.0, QTableWidget did not really support moving rows. It would instead move data into cells (like Excel). The example code shows a workaround, but since it calls code that inserts a row and deletes the old one, header data is lost in the process. My changes in Qt 6.8.0 implement support for moving rows in QTableWidget's internal model, so it's all fixed there. If you really need this feature in older versions of Qt, consider switching to QTableView.

Reorderable QTreeWidget

When using QTreeWidget:

☑ Call tableWidget->setDragDropMode(QAbstractItemView::InternalMove)

☑ Call item->setFlags(item->flags() & ~Qt::ItemIsDropEnabled); on each item, to disable dropping onto items

Conclusion about reorderable item widgets

Of course, you'll also need to iterate over the items at the end to grab the new order, like the example code does. As usual, item widgets lead to less code to write, but the runtime performance is worse than when using model/view separation. So, only use item widgets when the number of items is small (and you don't need proxy models).

Improvements to Qt

While writing and testing these code examples, I improved the following things in Qt 6.8:

QTBUG-13873 / QTBUG-101475 - QTableView: implement moving rows by drag-n-drop
QTBUG-69807 - Implement QTableModel::moveRows
QTBUG-130045 - QTableView: fix dropping between items when precisely on the cell border
QTBUG-1656 - Implement full-row drop indicator when the selection behavior is SelectRows

Conclusion

I hope this checklist will be useful when you have to implement your own reordering of items in a model or an item-widget. Please post a comment if anything appears to be incorrect or missing.

In the next blog post of this series, you will learn how to move (or even copy) items from one view to another.

The post Model/View Drag and Drop in Qt - Part 1 appeared first on KDAB.

KDAB Training Day - May 8th, 2025

Editor Team — Tue, 05 Nov 2024 12:56:00 GMT

KDAB Training Day - May 8th, 2025

Early-Bird tickets are on sale for the KDAB Training Day 2025 until 2025-03-31 23:59

The KDAB Training Day 2025 will take place in Munich on May 8th, right after the Qt World Summit on May 6th-7th. Choose to buy a combo ticket here (for access to QtWS and Training Day) or here (for access to Training Day only).

Seats are limited, so don't wait too long if you want to participate in a specific course. Tickets include access to the selected training course, training material, lunch buffet, beverages, and coffee breaks. Note: The Training Day is held at Hotel NH Collection München Bavaria, located at the Munich Central Station (not the same location as Qt World Summit).

Get your ticket

Why should you attend the KDAB Training Day?

With over 20 years of experience and a rich store of well-structured, constantly updated training material, KDAB offers hands-on, practical programming training in Qt/QML, Modern C++, 3D/OpenGL, Debugging & Profiling, and lately Rust - both for beginners as well as experienced developers.

All courses provided at the Training Day include central parts of the regular 3- to 4-day courses available as scheduled or customized on-site training. Choosing a compact, learning-rich one-day course, lets you experience the quality and effectiveness of KDAB’s usual training offerings.

Courses available at the KDAB Training Day 2025

QML Application Architecture
QML/C++ integration
Modern C++ Paradigms
Integrating Rust into Qt applications
Effective Modern QML
Integrating Custom 3D Renderers with Qt Applications

QML Application Architecture

In this training, we do a step-by-step walkthrough of how to build a QML-based embedded application from the ground up and discuss some challenges that are typically met along the way.

An important part of that journey is an investigation of where to put the boundaries between what you do in C++ and what you do in QML. We also look at some of the tools and building blocks we have available in QML that can help us achieve well-performing, well-structured, and well-maintainable applications.

This course is for

(Qt) developers looking to improve their understanding of how to construct maintainable and efficient larger-scale QML applications.

Prerequisite

Some real-world experience working on QML applications as well as a basic understanding of Qt and C++.

Get your ticket

QML/C++ Integration

In this training, we start with a recap of fundamentals:

How do we expose C++ API to QML?
How do we make data available to QML?

Afterward, we explore several more advanced techniques, often widely deployed within Qt's QML modules, such as Qt Quick.

This will answer questions such as:

How would I do a Loader like component?
How would I do a Layout like component?

This course is for

Qt/QML developers who are familiar with the QML APIs of QtQuick and related modules and who have wondered how these are implemented and want to use similar techniques in their project-specific APIs.

Prerequisite

Some real-world experience working on QML applications as well as a basic understanding of Qt and C++.

Get your ticket

Modern C++ Paradigms

Modern C++ emphasizes safer, more efficient, and maintainable code through higher-level abstractions that reduce error-prone manual work.

This training will explore key paradigms shaping recent C++ evolution, starting with value semantics in class design, which enhances code safety, local reasoning, and thread safety. We will examine modern C++ tools for creating value-oriented types, including move semantics, smart pointers, and other library enablers.

Next, we will look at expressive, type and value-based error handling.

Finally, we'll cover range-based programming, which enables clean, declarative code and unlocks new patterns through lazy, composable transformations.

This course is for

C++ developers who wish to improve the quality of their code, in particular those who wish to write future-proof APIs.

Prerequisites

Prior professional experience in C++. Experience with the latest C++ standards (C++20/23/26) is a plus. We will use several examples inspired by Qt APIs, so Qt knowledge is also a plus (but this is not going to be a Qt training).

Get your ticket

Integrating Rust into Qt Applications

In this step-by-step course, we start with a Qt/C++ application and add Rust code to it piece by piece. To achieve this, we will cover:

Use of Cargo (Rusts build system) with CMake
Accessing Rust code from C++ with CXX (and vice-versa)
Defining your own QObject types in Rust with CXX-Qt

We discuss when to use Rust compared to C++ to make the best of both languages and how to use them together effectively to make Qt applications safer and easier to maintain.

This course is for

Qt/C++ Developers with an interest in Rust who want to learn how to use Rust in their existing applications.

Prerequisites

Basic Qt/C++ knowledge, as well as basic Rust knowledge, is required. A working Qt installation with CMake and a working Rust installation is needed. We will provide material before the training day that participants should use to check their setup before the training.

Get your ticket

Effective Modern QML

In this training, we look into all the new developments in QML over the last few years and how they lead to more expressive, performant, and maintainable code.

This includes:
- The qt_add_qml_module CMake API
- Declarative type registration
- The different QML compilers
- New language and library features
- New developments in Qt Quick Controls
- Usage of tools like qmllint, QML Language Server, and qmlformat

The focus will be on gradually modernizing existing codebases with new tools and practices.

This course is for

Developers who learned QML back in the days of Qt 5 and want to catch up with recent developments in QML and modernize their knowledge as well as codebases.

Prerequities

Some real-world experience with QML and a desire to learn about modern best practices.

Get your ticket

Integrating Custom 3D Renderers with Qt Applications

Qt has long offered ways of using low-level 3d libraries such as OpenGL to do custom rendering. Whether at the Window, the Widget, or Quick Item level, the underlying rendering system can be accessed in ways that make it safe to integrate such 3rd party renderers. This remains true in the Qt 6 timeline, although the underlying rendering system has changed and OpenGL has been replaced by RHI.

In this course, we look at how the graphic stack is structured in Qt 6 and how third-party renderers can be integrated on the various platforms supported by Qt.

We then focus on the specific case of integrating Vulkan-based renderers. Vulkan is the successor to OpenGL; it's much more powerful but harder to learn. To facilitate the initial use of Vulkan, we introduce KDGpu, a library that encapsulates Vulkan while preserving the underlying concepts of pipeline objects, buffer handling, synchronization, etc.

This course is for

This course targets developers wanting to understand the recent state of the graphics stack in Qt, discover the fundamental principles of modern graphics API, and integrate their custom renderers in their applications.

Prerequisite

Prior knowledge of Qt will be required. A basic understanding of 3d graphics would be beneficial.

Get your ticket

Video from KDAB Training Day 2023 held in Berlin

The post KDAB Training Day - May 8th, 2025 appeared first on KDAB.

KDAB

Bind QML Values across an Arbitrary Number of Elements

Bind QML Values across an Arbitrary Number of Elements

The App: Display to Light Panels

The Code

Message Broker Singleton

Connecting Properties

QTimer to Delay Initialization

Conditional propagation

Real World Example

Automating Repetitive GUI Interactions in Embedded Development with Spix

Automating Repetitive GUI Interactions in Embedded Development with Spix

The Problem: Click Fatigue in GUI Testing

The Solution: Automating GUI Input with Spix

Setting up Spix in Your Project

1. Add Spix as a dependency

2. Register Spix in CMake

3. Link against Spix

4. Initialize Spix in your application

Where Spix Shines

1. Automating Logins with a Python Script

2. Screenshot Comparison

Example 1: Full-screen comparison

Example 2: Finding differences in the same UI

Recap

AI Coding with Qt: Qt AI Assistant for Qt Creator

AI Coding with Qt: Qt AI Assistant for Qt Creator

What is Qt AI Assistant?

Setting Up Qt AI Assistant

Features in Practice

Code Completion and Chat

Test Case Generation

Model Choice

Further Resources

Outlook

Using the Qt Logger in Rust with CXX-Qt

Using the Qt Logger in Rust with CXX-Qt

Getting started

Integrating with Tracing

Display Widget Windows in Qt Quick Applications

Display Widget Windows in Qt Quick Applications

Why Show a Qt Widget Window in a Qt Quick App

How to Show a Qt Widget Window in a Qt Quick App

Architecture Big Picture

Update CMakeLists.txt

Update main.cpp

The Interface Layer

Instantiating the Widgets Window

Make Properties Available to QML

Make Signals Available to QML

Final Product

Real World Use Case

Integrate QML Window's Background with the System's Color Palette

Integrate QML Window's Background with the System's Color Palette

Why is the color background revealed when the window size is increased?

How to Make Qt Quick Window Backgrounds Aware of Your System's Theme

Platform Style vs. Fixed Style

Crafting Seamless and Theme-Aware Qt Quick Applications

Model/View Drag and Drop in Qt - Part 3

Model/View Drag and Drop in Qt - Part 3

With Model/View separation

Setting up the view on the drag side

Setting up the model on the drag side

Setting up the view on the drop side

Setting up the model on the drop side

Using item widgets

On the "drag" side

On the "drop" side

Improvements to Qt

Conclusion

Model/View Drag and Drop in Qt - Part 2

Model/View Drag and Drop in Qt - Part 2

With Model/View separation

Setting up the view on the drag side

Setting up the model on the drag side

Setting up the view on the drop side

Setting up the model on the drop side

Using item widgets

For all kinds of widgets

Additional requirements for QTableWidget

Update `CMakeLists.txt`

Update `main.cpp`