KDAB

⬢ Distrobox: An In-depth Guide for Developers - Part 1

Wed, 23 Sep 2026 05:48:00 GMT

⬢ Distrobox: An In-depth Guide for Developers - Part 1

Motivation & Background

I generally use Ubuntu LTS at work, mainly due to how widely used and supported it is. However, there are many situations where it's helpful to use a different distro on the job.

Maybe I need to:

test against an older version of Ubuntu
reproduce a bug reported on another distro
test something on several distros
replicate a very specific environment
develop with an init system I don't have
acquire specific packages or versions from a different package repository

There are a few solutions to this problem.

We can use:

a virtual machine (hardware virtualization)
containers (docker / podman / etc.) (os-level virtualization)

Let's briefly consider each of these options.

Virtual Machines

Hardware virtualization is an easy and classic solution to this problem. This is the virtualization paradigm of virtual machines run by hypervisors & virtual machine monitors like qemu, virtualbox, VMware Workstation, and so forth. However, virtual machines come with some issues.

Firstly, the setup time can be quite long - downloading an iso, configuring the VM settings, installing the OS, setting up your environment with your preferred editor or IDE, shell, window manager or DE, and populating the system with libraries, compilers, language servers, and other tools. Then there can be additional time required to do things like enable clipboard sharing, which may not even work all that well for some more obscure distros. After all this, the VM itself both on disk and at runtime is a bit heavy. The hypervisor emulates hardware resources, including the entire storage device, and the bootloader and kernel are virtualized. This takes up quite a large chunk of persistent storage and typically has a relatively high memory footprint, often hindering the performance of applications, especially considering there is overhead for each resource that is not passed through to the host hardware.

It can be quite useful despite these shortcomings, but as the number of virtual environments grows, the more these issues are multiplied. Moreover, certain processes, like installing Qt from the online installer, are simply repeated over and over unnecessarily.

Containers

Containers are also a choice solution, as they circumvent these shortcomings. They virtualize at the OS userland (see OS-level virtualization) or application level. One way to think about this is the existence of several distinct userspaces, including the file system, on the same running kernel. Using the host's kernel eliminates most resource overhead and makes bootloader virtualization irrelevant. Clipboard sharing works out of the box, as the container's standard I/O is routed through a host terminal session when run interactively.

There are some key shortcomings here as well though: without further integration with the host machine, there is still a need to do significant setup to obtain tooling and libraries. Furthermore, it will not inherently have a graphical environment -- in order to open a graphical application, like a text editor, or perhaps a Qt project that you are intending to test in the first place, you will need to pass through sockets for X11 or Wayland from the host. It's quite powerful that the display doesn't need to be virtualized (and for instance a separate Xorg server doesn't need to run like in a virtual machine), but the setup for this can be cumbersome with many command line arguments. Containers are meant to be sandboxed from the host system, and share only explicitly specified resources from the host. However, this is again powerful -- we can mount parts of the host filesystem to pass through libraries, binaries, git configuration, ssh keys, project files, and so forth to share these resources between the host and any number of guests. The issue is again the tedium of setting these capabilities up for every container, both when installing and running.

Distrobox As A Solution To Shortcomings

Distrobox provides a solution to this. Due to the flexibility of containers, the aforementioned cumbersome tasks can be done automatically such that the workflow is massively simplified for the purposes of passing through graphical sessions, installing packages, and sharing parts of the host filesystem. Additional tooling provided by distrobox enables tighter integration between host and guest, like running host commands from within the guest without mounting, and exporting programs from the guest to host, so that they can be recognized by the host's application launcher for example. Distrobox automatically mounts a home directory from the host along with removable devices, journal, dbus, /dev, and many others, which can all be further configured. It can be used with several container management backends, namely docker, podman, and lilipod (a tool the authors of distrobox created).

Let's see an example of how much simpler this is. We can use the distrobox flag --dry-run to see what command is actually run on the backend when we issue a distrobox command on the host. Here I use podman as my container manager.

Doing so, we can see that the following distrobox command:

distrobox create -n tempalpine -i alpine -H /home/sus/temphome --init

translates to this podman command:

podman create
--hostname "tempalpine.sus"
--name "tempalpine"
--privileged
--security-opt label=disable
--security-opt apparmor=unconfined
--pids-limit=-1
--user root:root
--ipc host
--network host
--label "manager=distrobox"
--label "distrobox.unshare_groups=1"
--env "SHELL=bash"
--env "HOME=/home/sus"
--env "container=podman"
--env "TERMINFO_DIRS=/usr/share/terminfo:/run/host/usr/share/terminfo"
--volume /:/run/host:rslave
--volume /tmp:/tmp:rslave
--volume "/usr/bin/distrobox-init":/usr/bin/entrypoint:ro
--volume "/usr/bin/distrobox-export":/usr/bin/distrobox-export:ro
--volume "/usr/bin/distrobox-host-exec":/usr/bin/distrobox-host-exec:ro
--volume "/home/sus":"/home/sus":rslave
--volume /dev:/dev:rslave
--volume /sys:/sys:rslave
--volume /dev/pts
--volume /dev/null:/dev/ptmx
--volume /var/log/journal
--env "HOME=/home/sus/temphome"
--env "DISTROBOX_HOST_HOME=/home/sus"
--volume "/home/sus/temphome:/home/sus/temphome:rslave"
--volume /etc/hosts:/etc/hosts:ro
--volume /etc/resolv.conf:/etc/resolv.conf:ro
--annotation run.oci.keep_original_groups=1
--ulimit host
--systemd=always
--userns keep-id

--entrypoint /usr/bin/entrypoint
alpine
--verbose
--name "sus"
--user 1000
--group 1000
--home "/home/sus/temphome"
--init "1"
--nvidia "0"
--pre-init-hooks ""
--additional-packages ""
-- ''

which you can see mounts additional distrobox binaries like distrobox-init, distrobox-export, and distrobox-host-exec.

These tools themselves provide additional helpful functionality. distrobox-init, for example, is generally run automatically when a new container is initialized. It mounts several more directories, sets up sudo if needed, passes through xorg or wayland, creates a user and group for the user, and so on. This would all need to be done manually without that binary.

Thus, using distrobox saves a tremendous amount of time and effort, and wraps several reused arguments and additional commands to get such a container running quickly and without much thought.

Additional Background: Containers & OCI

For a fantastic introduction to containers and their usefulness, see this whitepaper: https://www.kdab.com/containers-in-embedded/

Further information can be found here: https://www.kdab.com/the-developers-guide-to-containers/

Some of the below may summarize, add to, or just repeat concepts in the above links.

Linux containerization is made possible by the cgroups & namespaces kernel features.

You have likely heard of, or used, docker before. Docker is the premier suite of tools for creating and deploying containers. Major contributors to the project include Microsoft, Cisco, Google, Huawei, IBM, and Red Hat.

Podman is a similar system, developed by Red Hat, that can act as a drop-in replacement for docker, as its API is identical.

Some advantages of podman over docker include:

lack of a daemon -- dockerd can become a single point of failure for all containers
rootless by default, while running rootless dockerd and docker-managed containers requires additional configuration

These tools are designed to be OCI-compliant. OCI (Open Container Initiative) is a set of open standards for containers. The specifications provide a common container image format and runtime model that enables using container images across multiple container management tools, and distribution of containers in a standardized packaging format. Tools can thus be made compliant with the OCI spec, and therefore should support any OCI-compliant container images. This is powerful, as someone can distribute a container image that should then work as a regular container spawned by docker or podman, and also work with distrobox, and other tooling around containers.

From Open Containers Initiative's About Page:

The OCI currently contains three specifications: the Runtime Specification (runtime-spec), the Image Specification (image-spec) and the Distribution Specification (distribution-spec). The Runtime Specification outlines how to run a “filesystem bundle” that is unpacked on disk. At a high-level an OCI implementation would download an OCI Image then unpack that image into an OCI Runtime filesystem bundle. At this point the OCI Runtime Bundle would be run by an OCI Runtime.
This entire workflow should support the UX that users have come to expect from container engines like Docker and rkt: primarily, the ability to run an image with no additional arguments:
docker run example.com/org/app:v1.0.0
rkt run example.com/org/app,version=v1.0.0

OCI Images more or less consist of metadata in json files, and a number of image layers. The image layers are essentially tar archives containing changesets on one another back to a base filesystem, which is, at its most simple, just an empty directory. The unpacked archives can be thought of like a diff format for an entire filesystem, and the manifest describes how these diffs are applied on top of one another to result in a filesystem that is runnable.

For more information, see the official specification pages.

Distrobox's Purpose In Terms of These Background Concepts

Distrobox's website provides a very concise summary of the tool that ties together all the content above:

The distrobox environment is based on an OCI image. This image is used to create a container that seamlessly integrates with the rest of the operating system by providing access to the user’s home directory, the Wayland and X11 sockets, networking, removable devices (like USB sticks), systemd journal, SSH agent, D-Bus, ulimits, /dev and the udev database, etc.

It also provides some compelling use cases:

Provide a mutable environment on an immutable OS, like ChromeOS, Endless OS, Fedora Silverblue, OpenSUSE Aeon/Kalpa, Vanilla OS, or SteamOS3
Provide a locally privileged environment for sudoless setups (eg. company-provided laptops, security reasons, etc…)
To mix and match a stable base system (eg. Debian Stable, Ubuntu LTS, RedHat) with a bleeding-edge environment for development or gaming (eg. Arch, OpenSUSE Tumbleweed, or Fedora with the latest Mesa)
Leverage a high abundance of curated distro images for docker/podman to manage multiple environments.

Some notable goals and features mentioned on the site include:

This project aims to bring any distro userland to any other distro supporting podman, docker, or lilipod. It has been written in POSIX shell to be as portable as possible and it does not have problems with dependencies and glibc version’s compatibility.
Refer HERE for a list of supported container managers and minimum supported versions.
It also aims to enter the container as fast as possible, every millisecond adds up if you use the container as your default environment for your terminal.

Intro to Using Distrobox

With the background out of the way, let's see how distrobox is used.

Note:
I'm using starship as my prompt, which will be relevant later. In my host environment, the prompt will look something like this:

~ 
🎄

~/exampledir 
🎄

instead of something like this:

~ $

~/exampledir $

You will notice that different containers often have different default prompts, and we will import my host's prompt into a container later in the article.

Creating Containers

A basic command to create a distrobox container for Alpine Linux looks like so:

~ 
🎄 distrobox create --image alpine

alpine is a shortname defined in /etc/containers/registries.conf.d/shortnames.conf. on my machine, it corresponds to docker.io/library/alpine.

We can also use -i instead of --image.

The container will automatically be named alpine here, automatically generated from the repository path docker.io/library/alpine. Attaching a tag to the path also affects the name. For instance, docker.io/library/alpine:latest or simply alpine:latest would result in the name being alpine-latest

The container's name is the way we interact with the container, to start, stop, enter, or delete it.

Let's say we want a gentoo image. There is no "gentoo" shortname in shortnames.conf, so we will provide the full path and tag:

~ 
🎄 distrobox create -i docker.io/gentoo/stage3:latest

This works fine, but it names the container stage3-latest. I might forget this name, so it's easier if i just call it gentoo. We specify a name for it with --name or -n:

~ 
🎄 distrobox create -i docker.io/gentoo/stage3:latest -n gentoo

Here is a list of supported container images that are officially tested. Other images can work too, but these are tested explicitly by the distrobox developers.

Entering Containers

Let's actually use a container and show what it looks like and how it can be useful.

~ 
🎄 distrobox enter alpine
Starting container...                   	 [ OK ]
Installing basic packages...            	 [ OK ]
Setting up devpts mounts...             	 [ OK ]
Setting up read-only mounts...          	 [ OK ]
Setting up read-write mounts...         	 [ OK ]
Setting up host's sockets integration...	 [ OK ]
Integrating host's themes, icons, fonts...	 [ OK ]
Setting up package manager exceptions...	 [ OK ]
Setting up distrobox profile...         	 [ OK ]
Setting up sudo...                      	 [ OK ]
Setting up user groups...               	 [ OK ]
Setting up kerberos integration...      	 [ OK ]
Setting up user's group list...         	 [ OK ]
Setting up existing user...             	 [ OK ]
Setting up user home...                 	 [ OK ]
Ensuring user's access...               	 [ OK ]

Container Setup Complete!
sus@alpine:~$

If we look at /lib in the container, we get our alpine image's lib files:

sus@alpine:~$ ls /lib
apk       ld-linux-x86-64.so.2  libc.musl-x86_64.so.1  libcrypt.so.1    libm.so.6        libresolv.so.2  libutil.so.1  modules-load.d
firmware  ld-musl-x86_64.so.1   libc.so.6              libgcompat.so.0  libpthread.so.0  librt.so.1      mdev          sysctl.d

This should be different from the /lib directory on my host machine and feel like its own machine, almost like a VM. But, distrobox also mounted my host's $HOME as a read-write directory. If we ls in ~ we will see the files from our host's ~.

We can use alpine's package manager to get programs we want inside the container:

sus@alpine:~$ vim
bash: vim: command not found
sus@alpine:~$ sudo apk add vim
(1/4) Installing vim-common (9.1.1012-r0)
(2/4) Installing xxd (9.1.1012-r0)
(3/4) Installing vim (9.1.1012-r0)
(4/4) Installing vim-doc (9.1.1012-r0)
Executing busybox-1.37.0-r9.trigger
OK: 546 MiB in 367 packages
sus@alpine:~$ vim

If we don't want it to specifically be an alpine package, and we already have the program on the host, we can also mount the host's installation files when we create the container. This grants us the flexibility to use what we already have where we can, and use the container distribution to get other packages.

Our installed programs also persist when we restart the container.

If we install something in a running container that we don't have on the host system:

sus@alpine:~$ sudo apk add qutebrowser
...
...
sus@alpine:~$ qutebrowser

This will open qutebrowser, which is a graphical application, using the host's X session (assuming you are running an Xorg session).

If we leave the container (Ctrl+D, exit, logout, etc.) and try to use qutebrowser:

sus@alpine:~$ 
logout

~ took 13m1s 
🎄 qutebrowser
Command 'qutebrowser' not found, but can be installed with:
sudo apt install qutebrowser

~ 
🎄

... we clearly can't use it, as the container has the program, not our host system. However, we can run it from the host system without entering an interactive container session by specifying a single command to run in the container, like so:

~ 
🎄 distrobox enter alpine -- qutebrowser

We can also export it from the container so we can invoke the command in distrobox from the host, and even make the program locatable by our application launcher.

Next Steps

In the next part of the series, we'll explore some more involved examples, including:

using additional flags to customize how our container is created and integrated with the host
further integrating the host with the guest

The post ⬢ Distrobox: An In-depth Guide for Developers - Part 1 appeared first on KDAB.

Using AI to modernize or migrate code

Nicolas Arnaud-Cormos — Wed, 02 Sep 2026 08:50:19 GMT

Using AI to modernize or migrate code

Let’s be honest, agentic engineering is the most disruptive evolution I’ve experienced in the field of software development (to be fair, I wasn’t there when we moved from cards to assembler).

AI agents are now able to do many things fast at good (to very good) quality. They are particularly good when it comes to code transformation: be it a code modernization or code migration.

Code transformation, the old way

KDAB engineers have completed many migrations over the last three decades: from Qt3 to Qt4 to Qt5 to Qt6, from MFC to Qt, from Motif to Qt… the workflow is always the same:

Find a piece of code you want to transform (a class, a dialog, a function),
Transform the code to fit your target (be it modernization or migration),
Test,
Peer-review.

At this point, the transformation is done. In order to apply the same transformation for the rest of the code, we try to automate it as much as we can. This means finding the recipe for the transformation and writing a script to complete it for yourself. I’m using script in a broad sense, it could be a simple Perl script, or a complete software aimed at transforming code (like KDAB’s migration tool Knut).

At this point, you can run the script on other parts of the code to migrate the rest of the software. Still, you need to follow these steps:

Apply the script to the code,
Finish the transformation if needed (sometimes, the script can only do 80%, as the last 20% are too difficult to automate),
Review,
Test,
Peer-review.

Never apply a transformation globally on the whole code, as it will make the last 3 steps almost impossible! Also, it’s important to note that there is always an infinity of variations of the code, meaning the script will most likely hit a corner case at some point or another, requiring manual help.

Any migration like this is time-consuming. Even if automation reduces the time to market, there are many manual steps required to ensure there are no regressions and the software is still working as expected.

Code transformation, the AI way

AI agents have completely changed the way developers are now working, especially as they are very good with code transformation. And we have seen many small or large codebases being migrated with the help of agents (for example bun, ladybird, google or even anthropic itself).

This leads us to think that with an infinite amount of tokens, one can basically migrate anything. There are now many services proposing AI code transformation with the premise that you just need to swipe your credit card (I will only link MALUS, humoristic one). Such one-click migration services are selling you a fantasy, a disaster waiting to happen.

As much as I find interesting reading those successful migrations, I’m more and more dubious that such migration could be done with a click on a button, based on our collective migration experience in KDAB.

Looking at the different steps done manually, you still need at least to review and test the software yourself. And even having 100% code coverage does not prevent from the agent making mistakes (read the excellent article on rewriting git to rust here).

Every migration project is unique, and it’s important to read the report of those AI-assisted migrations in detail, and why it worked. To my knowledge, none ended up with just one click on a button ;)

Code transformation, the KDAB way

The KDAB team has used AI agents on different projects requiring code transformation, which accelerates the development greatly.

And while all those projects were executed by different persons, the conclusions are always roughly the same.

Do not do any global transformation, but keep the changes small and local as much as possible. This allows the code to be reviewed by a human (as well as AI - nowadays almost a given), to do test focused on what’s changed and to correct and enhance the migration skills.

Write agent’s skills. As every migration is unique, you can easily create your own skills to share in the team and reuse during the migration. This replaces writing a “script” for automating transformation.

Test, test, test. Nothing will replace human testing, to ensure that all features are working as expected. You don’t want to release a new version of your software that has not been field tested beforehand.

In the end, all changes are still going through the CI, reviewed and tested by a human. AI definitely changed our approach to code transformation and improved our velocity. Still, the quality of the work we are delivering needs to be ensured.

Transformation Strategy

One helpful approach is to split the work into three phases:

Stabilization phase: before touching the actual migration, use AI to harden the existing codebase. Expand test coverage, prune dead code, and normalize formatting. This is not just cosmetic changes, it will reduce work, conflicts and regressions later on.
Pilot phase: the code transformation is done on a subset of the code. This allows to establish the architectural patterns, tooling and the general workflow for the migration.
Completion phase: once the foundation is established, the migration continues. The proven approach from phase 1 is applied to the rest of the code instead of trial-and-error.

This approach is preferred by KDAB, as we can set solid foundations during phase one based on our expertise and experience, and gradually let the customer take over the work during the completion phase.

Over 25 years of migrations, we’ve learned that codebases are more than just code: it’s a succession of (sometimes bad) decisions based on context, context that AI agents often lack, that could have ended up with convoluted code or architecture issues. KDAB’s job during the pilot phase is to identify those before blindly copying them in the new code. This allows detecting architectural drift and broken assumptions.

The people factor

We must address another important factor during a code transformation: ownership. AI agents can transform code at the speed of light, but they cannot mentor a team or build a consensus. A migration is only a success if the people who are going to inherit it understand it, trust it and maintain it.

This is why the completion phase is also so important, as it is not just a handover of the code, but a transition period of knowledge transfer, a time for KDAB’s engineers to explain the migration process, the decisions made and the new architecture if needed.

AI accelerates modernization, expertise makes it last

As of fall 2026, you should treat an AI as a highly productive, hyper-capable junior developer with a very short attention span. It is engineered for speed, but it requires consistent, expert supervision.

When it comes to code transformation, there is no "magic button." A successful project requires more than just raw power; it requires a clear roadmap and experience to avoid ‘been there, done that’ traps, as well as a buy-in from the team maintaining the code.

Starting with a rigorous pilot phase helps you validate your assumptions, test the agent’s performance against your specific architectural constraints, and determine whether the migration is truly worth the effort.

Ultimately, while AI agents have fundamentally shifted our approach to modernization, drastically increasing our velocity, they have not replaced the need for deep technical expertise. The value we deliver with the KDAB approach lies in ensuring that the final output is not just "transformed," but stable, maintainable, and built on a foundation that will last for the next decade.

The post Using AI to modernize or migrate code appeared first on KDAB.

OLE-Dispatch When Doing MFC/Qt Migration

Christoph Schleifenbaum — Thu, 20 Aug 2026 08:32:00 GMT

OLE-Dispatch When Doing MFC/Qt Migration

Most people who have ever ported an application from MFC to Qt know that at some point they have to integrate a QWidget into an MFC part of the user interface. Or the other way around, but that's a different story. Normally you would simply use a QWinWidget for that to do exactly what you want. But what happens if your application created the old MFC window as an OLE Control Extension (OCX)? In that case the easiest solution is to intercept the control name and provide it to your own factory providing the correct widget, which can then be embedded in a QWinWidget. Or you could use plugins to stick to the idea of it being DLLs. All roads lead to Rome. But what if your OLE based application uses the OLE-Dispatch way of initializing the controls? Setting properties, invoking methods, and so on?

I had exactly that problem and came up with a solution which glues OLE's IDispatch interface together with Qt's QMetaObject. That means you can access your QWidget's (or any other QObject) properties via the IDispatch interface provided by my QObjectDispatcher class. They only need to be declared via Qt's Q_PROPERTY macro. The same applies to slots and methods marked with Q_INVOKABLE.

Let's see how this is being used:

// This is the widget we're working with:
QWidget* someWidget = ...;

// Lets' create our dispatcher:
// You have to delete it yourself or let COM do it for you via IUnknown::AddRef/Release
QObjectDispatcher* dispatcher = new QObjectDispatcher(someWidget);

// The code until this point is the only part which is new in your application, as
// far as dispatching the calls/properties is involved. From here, it's exactly the same;
// from the OLE MFC application's perspective we often only have an IUnknown:
IUnknown* pUnknown = dispatcher;

// Now get the interface and start playing with it:
CComQIPtr<IDispatch> pDispatch(pUnknown);

// First we have to retrieve the index of the property we change
LPOLESTR name = "windowTitle";
DISPID dispId = -1;
pDispatch->GetIDsOfNames(IID_NULL, &name, 1, LOCALE_SYSTEM_DEFAULT, &dispId);

// Now that we have the index, we change the property
VARIANT varTitle = CComVariant("New window title");
DISPSPARAMS dispParams = { nullptr, nullptr, 0, 0 };
dispParams.rgvarg = &varTitle;
dispParams.cArgs = 1;
pDispatch->Invoke(dispId, IID_NULL, LOCALE_SYSTEM_DEFAULT, DISPATCH_PROPERTYPUT,
    &dispParams, nullptr, nullptr, nullptr);

As you can see the API of IDispatch is not fun to work with and there's no reason to use this except of making that kind of stuff work in existing MFC/OLE-applications while porting. I strongly advise against using it in new code.

How does that work? Well, the IDispatch interface works in two steps. First, you have to request the ID of the method/property you want to access via GetIDsOfNames. You can request several IDs at the same time. QObjectDispatcher traverses the methods of the handled QObject via the corresponding QMetaObject. It then returns the index of the method. If there’s no method found, it checks for a property. If it’s found, it returns the index of the property plus the number of methods, to be able to recognize the type afterwards. If neither a method nor a property by that name is found, an error is reported.

Let’s have a short look at how GetIDsOfNames roughly works. That example code cannot be used directly but gives you a rough idea of the implementation:

HRESULT QObjectDispatcher::GetIDsOfNames(REFIID riid, LPOLESTR* rgszNames, UINT cnames, LCID, DISPID* rgDispId)
{
    // GetIdsOfNames supports requesting several at the same time
    for (uint i = 0; i < cNames; ++i) {
        // note you cannot use QMetaObject::indexOfMethod directly, 
        // since it expects the fully qualified name
        auto indexOfMethod = []() { /* ... */ };
        const int methodIndex = indexOfMethod(rgszNames[i]);
        if (methodIndex != -1) {
          rgDispId[i] = methodIndex;
          continue;
        }
    }
    // now do the same for the properties...
    // [...]
    return S_OK;
}

In the second step you can call Invoke to either invoke a method or to access a property. For this you need to pass a struct DISPSPARAMS which contains the arguments. rgvarg is an array to several arguments which are stored in reverse order. QObjectDispatcher will now pick the method or property (depending on the id passed and whether you passed DISPATCH_PROPERTYPUT, DISPATCH_PROPERTYGET, or DISPATCH_METHOD) and call it. For this it has to translate the arguments. For method calling, they need to be translated to QMetaMethodArgument or QMetaMethodReturnArgument for the return value. For properties, we have to go through QVariant to be able to read/write the property via Qt’s Meta Object System.

Let’s also have a look at how Invoke works internally. Even here, this code piece is not complete and won’t work directly:

HRESULT QObjectDispatcher::Invoke(DISPID dispIdMember, REFIID riid, LCID, WORD wFlags, DISPPARAMS* pDispParams, VARIANT* pVarResult, EXCEPINFO*, UINT*)
{
    if (wFlags == DISPATCH_METHOD) {
        const QMetaMethod method = metaObject->method(dispIdMember);

        // translate return argument
        auto returnArgument = translateReturnArgument(method, pVarResult);

        // then call the method, translating all the arguments
        invokeMethod(method, m_object, returnArgument, translateArgument(0), ...);

        return S_OK;
    }

    // [...]
}

So, in your application, which expects a CWnd generated by some factory, you do the following:

Create a wrapper CWnd which you actually return to the caller. This CWnd will in some way provide access to an IDispatch instance like it was doing before your port
Create a QWinWidget residing inside of the CWnd.
Put your portedQWidget into the QWinWidget
Create a QObjectDispatcher working on your ported QWidget
Make your CWndreturn this QObjectDispatcher as IDispatch

Now your application should threat your ported widget as it was never ported. Of course, you have to provide the same properties and methods as the system expects using Qt's Meta Object System (Q_PROPERTY, Q_INVOKABLE).

There are, of course, some limitations:

You cannot overload names of methods as OLE doesn't allow that
Optional parameters are not supported, as QMetaMethod doesn't reflect that (or I simply haven't figured out, who knows…)
You have to provide a type-mapping for the argument types. The example project linked below provides only IUnknown*, int, and QString as these are the most common ones and show how it works
The example solution is not thread-safe

Find the complete code as a little example project on KDAB's GitHub repository at: https://github.com/KDABLabs/blogs-qt/tree/main/MFC-Migration-OLE-Dispatch

The post OLE-Dispatch When Doing MFC/Qt Migration appeared first on KDAB.

µ-Boosting Your CMake Productivity with Environment Variables

Wed, 12 Aug 2026 09:26:01 GMT

µ-Boosting Your CMake Productivity with Environment Variables

If you are working with C++ code chances are that you are using CMake to build your code, and for good reason. CMake is a powerful tool that allows you to target a wide range of compilers and platforms with a single buildsystem. Several large open source projects like Qt and KDE use CMake for that reason.

However, CMake does have a reputation for not always being the most ergonomic. For example, some useful options aren't enabled by default and need to be manually passed when invoking CMake, either from the command-line or an IDE.

For example, you might want to use the Ninja generator over the default one (e.g. Unix Makefiles on Linux) for faster builds. Enabling that is easy enough by passing -G Ninja on the command line. Remembering to do that every time a new build folder is created gets old fast though.

Another thing you might want to always enable is the CMAKE_EXPORT_COMPILE_COMMANDS option. This generates a compile_commands.json file that is used by tools like clang-tidy or the clangd language server (used for integration with code editors like Kate and Visual Studio Code).

One way to deal with repetitive CMake options are CMake presets. CMake presets are per-project configuration files that define sets of options to be applied. With that you can, for example, define presets for local development, CI builds, and release deployments, each with different options applied.

While CMake presets are a great tool for many use cases they don't help as much for quickly creating new projects. Fortunately, there's a different way to save yourself some typing: CMake environment variables.

CMake accepts configuration values not only from the command-line, but also environment variables from the system environment. For example, the default CMake generator is read from the CMAKE_GENERATOR environment variable. Likewise, you can enable compile_commands.json generation by setting the CMAKE_EXPORT_COMPILE_COMMANDS environment variable to ON.

By putting this

export CMAKE_EXPORT_COMPILE_COMMANDS=ON
export CMAKE_GENERATOR=Ninja

in your bashrc or equivalent you get those options enabled any time you create a new build folder, without specifying them manually every time. How handy is that?

This applies not only to cmake but also other tools provided by the CMake project. If you're using CMake, chances are that you're also using ctest to drive your test suite, and it, too, can be configured through environment variables. When invoking ctest on the commandline it will not show any of the tests’ output by default, making it hard to spot why a given test is failing. For this reason ctest accepts the --output-on-failure argument, which shows the test output for any failing tests. By setting CTEST_OUTPUT_ON_FAILURE=1 in the environment you can apply this to all ctest invocations automatically.

There are more environment variables than those even, see here for the full list.

That's not all, though. Not only can you set environment environment variables understood by CMake, you can also read custom environment variables in your CMake code:

if ($ENV{MY_CUSTOM_FLAG})
    do_something_special()
endif()

This can be useful for customizing the build process when using CMake parameters is not an option.

Environment variables are a small feature that's easy to overlook, but they can noticeably improve your day-to-day workflow. By moving your personal defaults into your shell configuration, you can spend less time remembering command-line options and more time writing code. And because these settings are applied automatically whenever you create a new build directory, they complement project-specific tools like CMake presets rather than replacing them. Hopefully this tip helps you make your CMake workflow just a little more convenient.

The post µ-Boosting Your CMake Productivity with Environment Variables appeared first on KDAB.

How long does it take for an Item to become visible?

Thu, 04 Jun 2026 14:18:00 GMT

How long does it take for an Item to become visible?

Frames skipped counter in application

How long does it take for an Item that you’ve just loaded to become visible? Answering this question allows for a way to detect what some users would perceive as "frame drops". I write that in quotes because Qt Quick only draws frames when needed, meaning it doesn't drop frames; but it can show them later than one would expect. That is what we would like to identify: When components are drawn late, and by how many milliseconds or frames are they late?

I've come up with a simple solution - code below the article - on how to measure this. Items being measured must inherit a class based of QQuickItem that has a connection on QQuickItem::visibleChanged. Its visible property should be false by default. When visible becomes true, a slot will start measuring elapsed time and create a direct connection to QQuickWindow::afterFrameEnd. Once the scene graph has submitted a frame, the slot will take the measurement and disconnect the connection that triggered it to prevent further frames from triggering this event.

That alone isn't enough, however. If there were other elements on the scene being animated (say from the render thread via an Animator), those would trigger a frame swap before our item would have had a chance to be drawn, causing our measurement to be taken prematurely.
We need a way of knowing when the frame that draws our component is the one that got swapped into view. Enter QQuickItem::ensurePolished. Calling this function ensures that QQuickItem::updatePolish will be called when the scene graph is ready to render our item. We override QQuickItem::updatePolish and use it to set a flag that’ll tell us that the next frame to come be displayed will correspond to the component we’re measuring. Lastly, we read this flag during the next call to QQuickWindow::afterFrameEnd, effectively using it to trigger the elapsed time measurement only when our item is swapped onto the screen.

There is a variable amount of time between the last user interaction and the moment a frame can be rendered; because of that, a measurement in milliseconds is only accurate to the average time that it takes for one frame to be rendered immediately after the previous frame. That turns out to be 1 second divided by the display's refresh rate. We can use Qscreen::refreshRate, which gives us this value in hertz. For a 60hz display, a frame's time (T) would be 1000 ms / 60 hz ≃ 16 ms. Any time measured that is between zero and T (16 ms) would mean an instant frame swap. If we divide the measured time by T, and apply a floor function to the result, we get the number of frames dropped while making the component visible, which is a more consistent measurement than the number of milliseconds passed. For a well optimized program the output would be zero, one, or a positive integer very close to that. For more information about the rendering process, you can read scene graph and rendering from Qt's documentation.

Make C++ items visible during their instantiation, or they won’t show up on screen. This QQuickItem subclass is different from its parent in that the Item is not visible by default. We set visible to false from the C++ constructor because the order in which initial properties are evaluated and assigned in QML differs depending on the approach used to instantiate the Item and assign its initial properties. You may set the initial visible property of an item in QML to false, then make it true during its instantiation as a delegate somewhere, only for the QML Engine to optimally evaluate its initial value solely to true, causing the visibleChanged signal to never be emitted because there was, effectively, no change to the visible property. Setting the visibility to false from the constructor in C++ is a simple way to guarantee that visibleChanged will be triggered upon any initialization of the visible property in QML.

The code for the QQuickItem subclass described in this article is documented below. Hope you find it useful. Reach out to us if you need help profiling software, would like to receive our training courses, or need help developing tools such as this.

Best regards, Javier

Code

#include <QQuickItem>
#include <QQuickWindow>

class TimedItem : public QQuickItem
{
    Q_OBJECT
    QML_ELEMENT

    Q_PROPERTY(qint64 timeToDisplay READ timeToDisplay NOTIFY timeToDisplayChanged FINAL)

public:
    TimedItem(QQuickItem* parent = nullptr) : QQuickItem(parent),
              m_elapsedTimer(new QElapsedTimer())
{
    setVisible(false);
    // When made visible, measure time to display
    QObject::connect(this, &QQuickItem::visibleChanged, this, &TimedItem::startMeasuringTimeToDisplay, Qt::DirectConnection);
};

qint64 timeToDisplay() {
    return m_timeToDisplay;
};

signals:
    void timeToDisplayChanged();

private:
    void startMeasuringTimeToDisplay()
    {
        if (isVisible())
        {
            // Reset
            m_frameReady = false;
            // Attempt to take measurement after frame swaps
            QObject::connect(window(), &QQuickWindow::afterFrameEnd, this, &TimedItem::measure,
            static_cast<Qt::ConnectionType>(Qt::DirectConnection | Qt::UniqueConnection));
            // Force polish, ensuring elapsed measurement is taken on the right frame
            ensurePolished();
            // Take initial measurement
            m_elapsedTimer->start();
        }
    }

    void updatePolish()
    {
        // The frame for this component will be rendered after this
        m_frameReady = true;
    }

    void measure()
    {
        // This will be called for every frame until the right frame has been rendered
        if (m_frameReady)
        {
            // Measure elapsed time
            m_timeToDisplay = m_elapsedTimer->elapsed();
            // Prevent measuring further frame
            QObject::disconnect(window(), &QQuickWindow::afterFrameEnd, this, &TimedItem::measure);
            // Propagate measured time
            emit timeToDisplayChanged();
        }
    }

private:
    qint64 m_timeToDisplay = 0;
    QElapsedTimer *m_elapsedTimer;
    bool m_frameReady = false;
};

The post How long does it take for an Item to become visible? appeared first on KDAB.

KDAB at Oxidize 2026, Berlin, September 14–16

Editor Team — Thu, 21 May 2026 07:23:38 GMT

KDAB at Oxidize 2026, Berlin, September 14–16

On September 14-16 2026, the Oxidize Conference returns to Berlin as the leading event for people using Rust in production. Co-hosted by KDAB and Ferrous Systems, Oxidize brings together industry leaders, engineers, and open-source contributors to share insights, tools, and success stories.

Why should you attend Oxidize?

Oxidize is the conference for engineers and technical leaders who want to see how Rust is being used in real-world production environments.

From embedded systems and safety-critical software to Rust/C++ interoperability, the event focuses on practical experience, hands-on learning, and honest discussions about adopting Rust at scale. It’s a chance to connect with experienced practitioners, learn from companies already building with Rust, and come away with insights you can apply directly to your own projects.

Workshop: Rust and C++ Can Be Friends

At this year’s Oxidize, KDAB engineers Nicolas Fella and Nicolas Qiu Guichard will lead the workshop “Rust and C++ Can Be Friends”.

C++ has been around far longer than Rust, and large codebases exist that are not feasible, economical, or necessary to rewrite in Rust. Therefore, it’s often advisable to integrate Rust into existing C++ codebases. Likewise, many C++ libraries are valuable to integrate into Rust projects.

Attending this workshop gives you a practical view of how mixed Rust/C++ systems are built and maintained in projects. Beyond the technical details, you’ll look at when interoperability makes sense, the trade-offs involved, and common integration issues that tend to appear in larger systems. It’s especially relevant if you’re working with legacy systems or introducing Rust gradually alongside existing C++ codebases.

In the workshop, Nicolas Fella and Nicolas Qiu Guichard will explore:

How to call Rust from C++ and vice versa using CXX
How to integrate a Rust library into a C++ application built with CMake
How to integrate a C++ library into a Rust application built with Cargo

Workshop seats are limited and sell out fast. Get your tickets and explore the full workshop lineup.

Workshop: Rust and C++ Can Be Friends

Panel: Navigating the Rust Job Market: Hiring and Being Hired

As Rust adoption continues to grow, the job market is maturing - and with that comes a new set of challenges for both candidates and employers. This panel will bridge the gap between expectation and reality in the Rust ecosystem. The panelists will explore the different archetypes of Rust roles - from working on the language itself, to working with it, to joining a company that happens to use it.

Till Adam (CCO at KDAB) will join industry experts to discuss what companies are really looking for when hiring Rust developers, how candidates can stand out, and how the ecosystem is evolving as Rust adoption increases across industries.

Panelists: Julia Sommer (Ferrous Systems), Julius Gustavsson (Volvo Cars), Tom Fleischmann (Accenture). Additional panelists to be announced.

Panel: Navigating the Rust Job Market: Hiring and Being Hired

Why KDAB is investing in Rust

Rust adoption is growing across the industries KDAB works in. It’s especially exciting to hear from practitioners with real-world Rust experience, because those insights help us better guide and support teams as they adopt Rust for their own applications.

To support this journey, KDAB has partnered with Ferrous Systems, building on their decade of Rust expertise to strengthen our approach as we continue deepening our involvement in the Rust ecosystem.

Meet the KDAB team at Oxidize

The KDAB team will be available on-site throughout the conference, with live demos and experts on hand to discuss topics including Rust/C++ interoperability, embedded development, modern software architecture, and more.

Till Adam (KDAB) and Florian Gilcher (Ferrous Systems) on Oxidize, the applied Rust conference

Oxidize 2024 Recap Video

The post KDAB at Oxidize 2026, Berlin, September 14–16 appeared first on KDAB.

Singleton Controllers in Times of Declarative QML

Thu, 07 May 2026 08:30:44 GMT

Singleton Controllers in Times of Declarative QML

Controller objects have been the main way to glue your QML UI to your application's actual implementation of the I/O and business logic. However, over the years, the way to actually expose that controller object has changed. And now, we contributed a change in QQmlEngine that allows you to change it once again, and we believe: for the better.

What are "controllers" anyway?

Conceptually, controllers are a thin glue layer between your business logic and your QML, exposing the data that the GUI needs in a format it can easily use. They are implemented as QObject-derived instances, usually with properties exposing values that may or may not be writable, as well as potentially some Q_INVOKABLE methods that can be triggered by the QML and maybe some signals.

Usually, these controllers are specific to a single logical group of values and functions within the wider application. An application may have a hand-full to dozens of them for a big system. Models exposing collections of data are usually made available as read-only properties returning a QAbstractItemModel-derived data model on these controllers.

Often, these controllers need to be instantiated with some initialization, as they need references to the business-logic objects they expose to the GUI, listen for signals to get notifications of changes, etc. And that's where the trouble starts...

Pre-Qt 6

Context properties

In the early days of QML, one would often use controller instances exposed to QML as context properties. Doing that allowed one to instantiate the controllers under control of C++, giving it all the references the objects needed at that time. We would often expose them to QML using a naming pattern like starting the name with a double underscore __someController so that it was easy to recognize in the QML code. Using context properties however is no longer recommended. Their lookup is slow, and the QML compilers cannot reason about them, so code using them cannot be optimized. Nor is tooling available to help the QML programmer, as code completion and the likes are not possible.

Singleton Instances

Then came the qmlRegisterSingletonInstance method. This method allowed one to register a QML singleton, but it would return the instance that you passed it as an argument and that you could instantiate however you needed. That was a good solution, but it didn't have a long useful life as it didn't mesh well with the declarative registration and it had issues with the one instance being the instance for every QML engine in your application (if you had more than one).

Post-Qt 6

Since Qt 6, the recommended way to write QML is to create QML modules using declarative registration for C++-based objects. That has many benefits in terms of tooling and optimization, so it's good practice to do this. But it also meant that since Qt 6, one could no longer mix-and match imperative registration with declarative: you either used the one, or the other; which rendered the qmlRegisterSingletonInstance method above useless.

There are many possible approaches that I have seen being applied to still control the creation of controller objects, usually by registering a singleton that has a static create factory function and returning some C++ singletons there or something along those lines. That works, but isn't very elegant. An alternative approach is using initial properties on the root object, but that either requires accessessing the root id from other QML files or propagating the controllers all the way down the stack of items. Neither is a great solution for different reasons. My colleague Javier Cordero Pérez is making a couple of videos about ways to do this, so I won't go into detail here. These videos will be added here once they have been released.

New approach

That building this connection between C++ and QML was so inelegant - despite being so important - inspired me to finally take matters into my own hands and write a patch.

The result is available starting with Qt 6.12 onward and it combines the good things of qmlRegisterSingletonInstance and the declarative registration: you still register your controller type as a QML singleton so that the type is fully known by the tooling and access to it can be optimized. But we gain back the ability to provide a ready-made instance to the QML engine.

setExternalSingletonInstance

The API on QQmlEngine gained a single new method: QQmlEngine::setExternalSingletonInstance. It allows you to provide an instance of a type declared as a singleton as the instance to use in any QML running in that engine, just like you could with qmlRegisterSingletonInstance. In contrast to that old registration function, however, you call this method on your specific QQmlEngine instance. Note that the type has to be (declaratively) registered as a singleton type for this call to work. If you are using more than one engine, it is up to you to decide if you want to provide the same instance to these different engines, or have separate instances.

This simple method gives you back an elegant, supported way to fully control the instantiation of the QML singleton, and thus easily connect it to your business logic or whatever else you need to with it. However, it is up to you make sure that you do this call before any QML code actually tries to access the singleton. Otherwise, the engine will (try to) create it's own instance as it used to. You cannot replace an already existing singleton instance, so once there is one, it is the one.

It’s up to you to make sure that the provided singleton instance outlives the QML that depends on it. You can do that in any way that works in your context, but you could consider parenting the instance to the QQmlEngine instance, ordering the variables containing them on the stack correctly, or using QQmlEngine::setObjectOwnership to hand ownership of the singleton to the QML engine.

QML_UNCREATABLE for singletons

If you are providing your QML singleton instance yourself anyway, you logically also don't need it to be creatable by the engine either - although, it still can be, of course. If your controller type has a non-default constructor - perhaps to take in some references to your business logic instances - you can now mark your singleton with QML_UNCREATABLE, just like you can with other QML types. If you do that, you no longer need to supply a factory function (and even if you do, it won't be used).

Of course, if you mark a singleton as uncreatable, it is up to you to make sure you actually supply an instance via QQmlEngine::setExternalSingletonInstance before the singleton is needed from QML.

The post Singleton Controllers in Times of Declarative QML appeared first on KDAB.

Building Reusable Slint UI Libraries with Rust Crates

Wed, 22 Apr 2026 09:01:00 GMT

Building Reusable Slint UI Libraries with Rust Crates

Slint is a UI framework, implemented in Rust, with support for C++, WASM, and Python. Find out more at https://slint.dev.

One thing that is needed for any UI framework is the possibility to extend the framework with your own custom UI components. That may not sound particularly special - Qt and QML already offer plenty of ways to do this, which is the reason why I won’t get into that here. As a modern programming language, Rust offers additional functionality through “crates,” which are published and distributed on crates.io, the central package registry for Rust. To extend the Slint UI framework, the natural way to accomplish this is to implement a Rust crate. In my case, this was done to provide a custom chart library. Slint is a declarative UI, meaning the UI components are described in the Slint language. For the chart library, the UI and data types are implemented in the Slint language (.slint files). The rendering of the chart is implemented in native Rust code.

So, what's the deal here, you may ask? Let's get into how Slint works under the hood. The .slint files are compiled by the slint-compiler into Rust-code (or into C++ code in the case of a C++ application). The output from the slint-compiler is included into the Rust application via the slint::include_modules!() macro. So far, so good. The Slint application (which makes use of the chart library) needs to use UI components and types that are provided by the chart library / crate. Until now, it has not been possible to export components and types provided by previously slint-compiled Rust code.

This is what I have been working on, implemented in the following PR: https://github.com/slint-ui/slint/pull/9329. The changes were merged upstream and became part of the 1.14 release. They were introduced as an experimental feature that needs to be explicitly enabled (slint-build/experimental-module-builds). Since then, Slint has moved on to the 1.16 release since April 2026. Implementing this required substantial changes to the slint-compiler.

When building the Rust crate, the slint-compiler needs to know that it is building a library / extension. A Slint library does not have a MainWindow, and some types in the generated Rust code needs to be declared pub so the application can access them. To configure the slint-compiler, the build.rs looks like this:

fn main() {
    let config = slint_build::CompilerConfiguration::new().as_library("MyLibrary").rust_module("mymodule");
    slint_build::compile_with_config("mylib.slint", config);
}

For the application we just need to add the dependency in Cargo.toml:

[dependencies]
my-library = { ... }

In the .slint file, using a type or component exported by my-library is done as follows:

import { Foo } from "@MyLibrary"

The slint-compiler will automatically determine that the import @MyLibrary comes from the Rust my-library crate. This “magic” is actually done by the Cargo build system. When building my-library, the following environment variables are set:

DEP_MYLIBRARY_SLINT_LIBRARY_MODULE=mymodule
DEP_MYLIBRARY_SLINT_LIBRARY_NAME=MyLibrary
DEP_MYLIBRARY_SLINT_LIBRARY_PACKAGE=my-library
DEP_MYLIBRARY_SLINT_LIBRARY_SOURCE=/absolute/path/to/mylibrary.slint

These are picked up by the slint-compiler, which then knows that imports from @MyLibrary come from the my-library crate. The slint-compiler still needs to parse mylibrary.slint and add the used types into the slint-compiler type loader. In the final step, when Rust code is generated, imports from @MyLibrary result in Rust use ... statements instead of generated code.

Now let’s look at Slint globals, using a simple example:

export global MyAppData {
    in property <int> some-value: 42;
    callback update-data();
}

Conceptually, Slint global components are just singleton instances. Technically, all Slint global components are created when the application MainWindow is created and are associated with it. When the MainWindow is destroyed, all global components are destroyed as well. The slint-compiler now needs to know which external libraries are imported, so it can also create and initialize the global components defined in those libraries. A crate can also depend on another crate. For example, let's say we have crate A, B , and C, both crate A and B have a dependency to crate C. The Slint globals for crate C will be instantiated twice. Due to that the current implementation does not yet cover all edge cases related to creating and initializing Slint global components. This is something that needs to be improved, but apart from that, it works fine.

There is still quite some work to do before this feature can move out of experimental status, but so far it is promising and already good enough to start building libraries and extensions for the Slint UI framework.

The post Building Reusable Slint UI Libraries with Rust Crates appeared first on 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.

Hotspot v1.6.0 released

Editor Team — Fri, 13 Mar 2026 07:19:00 GMT

Hotspot v1.6.0 released

Hotspot is a standalone GUI designed to provide a user-friendly interface for analyzing performance data. It takes a perf.data file, parses and evaluates its contents, and presents the results in a visually appealing and easily understandable manner. Hotspot’s goal is to offer a modern alternative to perf report, making performance analysis on Linux systems more intuitive and efficient.

Version 1.6.0 introduces powerful new features, improved workflows, and numerous bug fixes to make profiling even smoother.

ChangeLog for Hotspot v1.6.0

This release focuses on usability improvements and extended analysis capabilities. The most notable additions are:

Support for archived perf files (e.g. perf.data.zip)
Regex filtering in the flamegraph
Tracepoint support
Various bug fixes and stability improvements

Open Archived perf Files Directly

Hotspot can now open perf recordings stored inside archives such as perf.data.zip.

This simplifies sharing profiling results, storing CI artifacts, and working with compressed recordings - no manual extraction required.

Regex in the Flamegraph

The Flamegraph view now supports regular expression filtering.

This makes it much easier to:

Match complex symbol patterns
Focus on specific subsystems or namespaces
Quickly narrow down large profiling datasets

Especially for large C++ codebases, regex search significantly speeds up navigation.

Regex in the flamegraph

Tracepoint Support

Hotspot 1.6.0 introduces support for tracepoints captured via perf.

This enables analysis of event-based data in addition to traditional sampling, giving deeper insight into system and runtime behavior.

Tracepoints

Bug Fixes and Improvements

As usual, this release also includes numerous smaller fixes, UI refinements, and internal cleanups to improve overall stability and user experience.

For a complete overview of all changes, see the full changelog on GitHub.

Happy profiling!

Videos

Hotspot - A GUI for perf report:

Hotspot Demo from Embedded World 2022:

The post Hotspot v1.6.0 released appeared first on KDAB.