KDAB

Hotspot v1.6.0 released

Editor Team — Fri, 13 Mar 2026 07:19:47 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.

Weighing up Zngur and CXX for Rust/C++ Interop

Thu, 05 Mar 2026 08:13:33 GMT

Weighing up Zngur and CXX for Rust/C++ Interop

With Rust consistently proving itself as a good replacement for C++ due to its type system, memory safety, and macros, many industry giants are starting to write or rewrite things in this more modern systems language.

That being said, the maturity, and broad ecosystem of C++ cannot be understated, and many companies have decades of code written in established C++ tech stacks, for example the Qt framework. This is where interoperability comes in, allowing Rust's modern features and package management to be paired with existing C++ knowledge and codebases, or call rigorously tested and optimised C++ libraries in a new Rust codebase.

Now that CXX - the most widely adopted Rust with C++ interop library - is mature and kept very stable, we would like to explore Zngur, another emerging library in this space.

Design Philosophies

One important differentiator between these libraries is their aims, with Zngur attempting to support a larger subset of semantics, with the cost of some performance, ergonomics and safety, whereas CXX preaches safety and a reduced feature set, with the claim of no overhead. As stated in the Zngur documentation:

"Zngur also makes safety guarantees but also tries to be powerful enough to handle arbitrary signatures from Rust code"

One example where Zngur is less restrictive than CXX is that it permits owned objects across the FFI boundary, using the #cpp_value directive. Zngur also avoids guarantees around Send and Sync as we will discuss in the multithreading section.

I personally found Zngur a little easier to set up, but it does have a more convoluted way of specifying the language boundary, which is explained below. Additionally, Zngur aims to keep most of the generated and glue code in the C++ side, as opposed to splitting it over Rust and C++, and this can potentially make it easier to debug, but also eschews some of Rust's safety guarantees. On the other hand, the many thousands of lines of C++ code can sometimes be redundant and difficult to search through.

Technical Dive

Now let's get into the nitty-gritty details of this comparison that separate these two frameworks. Zngur poses some advantages over CXX with more arbitrary container support, and trait implementations with dynamic dispatch. On the other hand, CXX has a more solid build setup, much larger community, and external support for async Rust, all of which we will explore below.

Containers

One of Zngur's selling points is its claim to support most container types with "almost full API", whereas CXX has a more limited selection. Some of these types include nesting vectors such as Vec<Vec<T>>, HashMap<K, V>, and Arc<dyn T> (we will discuss trait objects next).

This first class support comes with a cost, however, as each type needs to be manually specified, e.g. Vec<Vec<i32>> and Vec<Vec<String>> need to be separately declared (and even String needs to be declared). This quickly compounds, as for each type, you must specify all std library methods you want to use, which can lead to very large files.

CXX has good support for many container types with "out of the box" use, and more complex types can be wrapped with the newtype pattern, and used opaquely, with slightly reduced ergonomics. CXX also has the very powerful feature of being able to automatically generate the appropriate specializations for the types you need. In most cases, CXX has enough support for standard containers - and makes using them a lot simpler - but if your app is going to have a lot of complex types, you may be better going with Zngur.

Nested Vectors in Zngur

Here we have an example IDL (interface description language) file declaring a 2D vector. Zngur uses separate files for it's boundary description, whereas CXX has the bridge macro, but these perform the same role.

// Exposes nested vector types
mod vec {
    type Vec<i32> {
        #layout(size = 24, align = 8);
        wellknown_traits(Debug);
        fn new() -> Vec<i32>;
        fn push(&mut self, i32);
        fn len(&self) -> usize;
    }

    type Vec<Vec<i32>> {
        #layout(size = 24, align = 8);
        wellknown_traits(Debug);
        fn new() -> Vec<Vec<i32>>;
        fn push(&mut self, Vec<i32>);
        fn len(&self) -> usize;
    }
}

See here for the full file

We can construct, move, and call functions with the type in C++ like

auto row1 = to_vec({1,0,0});
auto row2 = to_vec({0,2,0});
auto row3 = to_vec({0,0,1});

auto matrix1 = Vec<Vec<int32_t>>::new_();
auto matrices = Vec<Vec<Vec<int32_t>>>::new_();

matrix1.push(std::move(row1));
matrix1.push(std::move(row2));
matrix1.push(std::move(row3));

matrices.push(std::move(matrix1));

zngur_dbg(rust::crate::determinants(matrices));

Full Example

The template has been declared in C++ to shorten rust::std::vec::Vec<T>, and the to_vec helper is used so rows can be created with initializer lists.

The Rust function is simply calculating matrix determinants, and performing this on a vector of matrices. This way we make use of 1D, 2D and 3D vectors across the boundary.

/// Treating nested vector like a 3x3 matrix, returns list of 
pub fn determinants(matrices: &Vec<Vec<Vec<i32>>>) -> Vec<i32> {
    let mut result = vec![];
    for m in matrices {
        // Naming components to make formula easier to read
        let a = m[0][0];
        // ...
        let i = m[2][2];

        let det = a*e*i + b*f*g + c*d*h - (c*e*g + a*f*h + b*d*i);
        result.push(det);
    }

    result
}

Full Example

Nested Vectors in CXX

CXX does not support bridging arbitrary containers, but this can easily be remedied using the newtype pattern. Although they must then be opaque, you can put more complex containers behind a struct, and pass that over the boundary, like so:

// We define a newtype, and can give it some basic methods
#[derive(Debug)]
struct Matrix {
    inner: Vec<Vec<i32>>,
}

impl Matrix {
    fn get_row(&self, row: usize) -> &Vec<i32> {
        &self.inner[row]
    }
}

Full Example

And then adding some C++ code, we can use this newtype to perform some calculations

// We use an app class to hold our methods
ExampleApp::ExampleApp() {}

std::unique_ptr<ExampleApp> new_app() {
  return std::unique_ptr<ExampleApp>(new ExampleApp());
}

// Calculating the determinants the same as the Zngur example
int32_t ExampleApp::calculate_determinant(const Matrix &m) const {
  auto row0 = m.get_row(0);
  auto row1 = m.get_row(1);
  auto row2 = m.get_row(2);
  
  // We can use the index operator, because CXX maps Rust Vec to C++ vector, something not possible in Zngur
  auto a = row0[0];
  // ...
  auto i = row2[2];

  auto det = a*e*i + b*f*g + c*d*h - (c*e*g + a*f*h + b*d*i);
  return det;
}

Full Example

We then specify the boundary using the CXX bridge macro:

#[cxx::bridge]
mod ffi {
    extern "Rust" {
        type Matrix;
        fn get_row(self: &Matrix, row: usize) -> &Vec<i32>;
    }

    unsafe extern "C++" {
        include!("cxx-example/include/example.h");
        type ExampleApp;

        fn new_app() -> UniquePtr<ExampleApp>;
        fn calculate_determinant(&self, matrix: &Matrix) -> i32;
    }
}

Full Example

This can then be called like so in our main function:

fn main() {
    let app = ffi::new_app();
    let m = vec![vec![1, 2, 3], vec![4, 5, 0], vec![0, 0, 9]];
    let mat = Matrix { inner: m };
    let det = app.calculate_determinant(&mat);
}

Full Example

Although similar, both approaches have their strengths and weaknesses.

Enums

Whilst CXX has support for basic Rust enums, Zngur's built-in support for tagged union type enums (variants that contain data) is very powerful for Rust users.

This means that defining Option<T> and Result<T, E> in your crate is trivial, and these are two of the most used data types in Rust. This includes constructors, e.g. instantiating Ok(value) in C++ code. Of course, the developer still needs to specify that they want to use these types in the IDL file.

On the other hand, the CXX community has a solution for this, in that if you need support for more than basic enums, there exists cxx-enumext, which provides the support for much more complex enums, including data with lifetimes, and boxed data. There is certainly something to be said for Zngur's wider support for declaring these algebraic data types, however.

Traits

Another strength of Zngur's is implementing traits in C++. For example, as a replacement for abstract classes or interfaces, you can define a Rust trait, and implement it in C++, for either Rust or C++ types, allowing polymorphism over the boundary via constructing a Box<dyn MyTrait>.

For example, as a replacement for abstract classes or interfaces, you have two options when it comes to traits:

Implement your trait for Rust objects using C++
Implement your trait for a C++ class, by inheriting from it in C++

One caveat to this, however, is that Zngur provides a make_box C++ helper for using these objects polymorphically, but is only accessible to C++ classes that inherit from a trait, not Rust objects with Rust or C++ implementations. This does, however, seem like something that could be easily rectified in the future. Our workaround for this, is simply adding a method to your trait like so:

trait MyTrait {
    // Your trait methods here
    fn as_my_trait(self) -> Box<dyn MyTrait> where Self: Sized + 'static { 
        Box::new(self)
    }
}

In CXX this type of behaviour would be done via a UniquePtr instead and a C++ base class. This has its benefits and tradeoffs, but the first class support for trait objects in Zngur bodes well for leveraging the power that traits bring. Moreover, C++ lambdas can be turned into Box<dyn Fn> objects, allowing them to be passed to Rust functions like map like a Rust closure.

With this IDL definition:

mod crate {
    // Declaring the methods we want to use in the trait
    trait MediaType {
        fn author(&self) -> ::std::string::String;
        fn title(&self) -> ::std::string::String;
        fn rating(&self) -> u8;
        fn media_type(&self) -> ::std::string::String;
    }

    // Box type must be declared too
    type Box<dyn crate::MediaType> {
        #layout(size = 16, align = 8);
    }

    // A rust function to display Movies, Songs, Albums, and any new media types
    // Simply prints out the author, title and rating in a pretty format
    fn display_media(Box<dyn MediaType>);

    type Movie {
        #layout(size = 56, align = 8);
        wellknown_traits(Debug);

        constructor {author_name: ::std::string::String, movie_title: ::std::string::String, movie_rating: u8};
        fn as_boxed(self) -> Box<dyn MediaType> use MediaType; // The use keyword specifies this method comes from the trait

        field author_name (offset = 0, type = ::std::string::String);
        field movie_title (offset = 24, type = ::std::string::String);
        field movie_rating (offset = 48, type = u8);
    }

    type Song {
        #layout(size = 56, align = 8);
        wellknown_traits(Debug);

        constructor {author: ::std::string::String, title: ::std::string::String, rating: u8};

        field author (offset = 0, type = ::std::string::String);
        field title (offset = 24, type = ::std::string::String);
        field rating (offset = 48, type = u8);
    }
}

// This block declares that we are going to implement the trait using C++
// This is done using the Impl template provided by Zngur
extern "C++" {
    impl crate::MediaType for crate::Movie {
        fn author(&self) -> ::std::string::String;
        fn title(&self) -> ::std::string::String;
        fn rating(&self) -> u8;
        fn media_type(&self) -> ::std::string::String;
    }
}

Full File Here

We can implement traits for our Rust types using C++ like so

// Trait impls
String
rust::Impl<Movie, MediaType>::author(
    rust::Ref<Movie> self) {
    // String have to be clone to be owned in C++ since they are allocated by the rust heap, so cannot be moved easily
  return self.author_name.clone();
}

String
rust::Impl<Movie, MediaType>::title(
    rust::Ref<Movie> self) {
  return self.movie_title.clone();
}

String
rust::Impl<Movie, MediaType>::media_type(
    rust::Ref<Movie> _self) {
  return "Cinema"_rs.to_owned();
}

uint8_t
rust::Impl<Movie, MediaType>::rating(
    rust::Ref<Movie> self) {
  return self.movie_rating;
}

Full Example

We can then access boxed trait objects in a few ways:

Inherit from the trait, and use the make_box helper

// Implementing MediaType for rust::Song
class SongMedia : public MediaType {
  Song song;

public:
  SongMedia(Song s) : song(std::move(s)) {}

 ...
};

...

// Create an instance from a rust::Song
auto song_media = SongMedia(std::move(song));

// Call its methods
auto artist = song_media.author();
zngur_dbg(artist);

// Get a boxed trait object using the Zngur helper
auto boxed_song_media = Box<Dyn<MediaType>>::make_box<SongMedia>(std::move(song_media));
display_media(std::move(boxed_song_media));

Full Example

Use the rust trait implementation

// Using the rust as_boxed method as shown above (called as_boxed here)
auto my_album_as_media_type = my_album.as_boxed();
display_media(std::move(my_album_as_media_type));

Use the C++ trait implementation

// display_media will use the C++ implentations, but note as_boxed comes from the trait in Rust.
auto my_movie_as_media_type = jaws.as_boxed();
display_media(std::move(my_movie_as_media_type));

Note that the trait contains an implemented method as_boxed, so C++ implementations can use it: fn as_boxed(self) -> Box<dyn MediaType> where Self: Sized + 'static { Box::new(self) }

These 3 options permit flexible use of traits implemented in Rust or C++.

In CXX, we use a different idiom, defining a base class, and then using UniquePtr to get access to it in Rust.

// Abstract base / interface
class Media {
    public:
        virtual rust::String media_type() const = 0;
        virtual rust::String author() const = 0;
        virtual rust::String title() const = 0;
        virtual int rating() const = 0;
        const Media& as_media() const { return *this; }
};

Complete Header File

This acts as our "trait" since we need to override the virtual methods, and the as_media method is available on inheritors. It use the dereference in the return so that it can be coerced into the base class.

We can then define our inheriting classes:

class Movie : public Media {
public:
    Movie(rust::String title, rust::String author, int rating) : m_title(std::move(title)), m_author(std::move(author)), m_rating(rating) {}
    rust::String author() const override {
        return m_author;
    }

    rust::String title() const override {
        return m_title;
    }

    rust::String media_type() const override {
        return rust::String("Movie");
    }

    int rating() const override {
        return m_rating;
    }

private:
    rust::String m_title;
    rust::String m_author;
    int m_rating;
};

And do the same for our Song class.

We can then define our methods to obtain a unique pointer:

std::unique_ptr<Movie> make_movie(rust::String title, rust::String author, int rating) {
    return std::make_unique<Movie>(title, author, rating);
}

std::unique_ptr<Song> make_song(rust::String title, rust::String author, int rating) {
    return std::make_unique<Song>(title, author, rating);
}

// function to print all media types in a readable manner
void display_media(const Media& m) {
    ...
}

Full Example

We can then expose them in the bridge of the main file like so:

#[cxx::bridge]
mod ffi {
    unsafe extern "C++" {
        include!("cxx-example/include/media.h");

        type Media;
        type Movie;
        type Song;

        fn make_movie(title: String, author: String, rating: i32) -> UniquePtr<Movie>;
        fn make_song(title: String, author: String, rating: i32) -> UniquePtr<Song>;

        fn as_media(self: &Movie) -> &Media;
        fn as_media(self: &Song) -> &Media;

        fn display_media(m: &Media);
    }
}

And use them in main,

fn main() {
    // Media
    let jaws = make_movie("Jaws".to_owned(), "Steven Spielberg".to_owned(), 8);
    let fur_elise = make_song("Fur Elise".to_owned(), "Mozart".to_owned(), 5);

    display_media(jaws.as_ref().unwrap().as_media());
    display_media(fur_elise.as_ref().unwrap().as_media());
}

Async and Threading

On the other side of the coin, CXX has support for async rust planned, allowing async functions to be simply declared in the bridge, but currently they offer a workaround for calling async functions via a new type struct, containing a oneshot channel (futures crate). Furthermore, the cxx-async crate adds support for async tasks, and is fairly well established, so it can be a robust addition to your project if you need async.

Zngur on the other hand does not have this support planned, and makes no mention of how to implement it yourself. Zngur also doesn't do any checks, however, around Send and Sync - despite having support for Arc<T> (a smart pointer used in threaded situations), as opposed to CXX's static assertions, which make multithreaded situations much safer.

Project Setup

A further benefit of CXX is its significantly higher adoption - being used in Chromium and Android - as well as its better written and more complete documentation. We did find that Zngur had a slightly simpler project setup, being that you can simply generate the glue code, then use your existing C++ build setup, along with cargo to generate a library, or alternatively compile a C++ library, and link to your Rust binary. This independence from a specific build system makes it quick to integrate with what your already have. It also has the added benefit of not requiring any dependencies, simply being a CLI tool which generates the glue code for you.

As we have often seen with CXX throughout the blog, this functionality does exist in some form, namely the cxxbridge command. This allows you to take a CXX bridge file, and manually generate the glue code.

For Cargo builds, CXX recommends cxx-build to obtain a CC builder, and the Zngur crate offers a builder struct to provide a similar CC interface, for building the glue code. Despite being harder to set up than the command line system, this offers deep configuration for more advanced use cases and could even allow combining Zngur with CXX. Corrosion also has experimental helpers for CXX builds with CMake (but there are no blockers on Zngur being supported here too in the future). Using a makefile or justfile to invoke build commands can also simplify the build process.

An example Zngur build script for a simple project might look like this:

use zngur::Zngur;

fn main() {
    build::rerun_if_changed("main.zng");
    build::rerun_if_changed("prelude.zng");
    build::rerun_if_changed("trait_objects.zng");
    build::rerun_if_changed("nested_types.zng");
    build::rerun_if_changed("main.cpp");
    build::rerun_if_changed("nested_types.rs");
    build::rerun_if_changed("trait_objects.rs");

    let crate_dir = build::cargo_manifest_dir();

    // Generate glue including the header, implementations (generated.cpp) and Rust code.
    Zngur::from_zng_file(crate_dir.join("main.zng"))
        .with_cpp_file(crate_dir.join("generated.cpp"))
        .with_h_file(crate_dir.join("generated.h"))
        .with_rs_file(crate_dir.join("./src/generated.rs"))
        .generate();

    let my_build = &mut cc::Build::new();
    let my_build = my_build.cpp(true).std("c++17");
    let my_build = || my_build.clone();

    // Build the C++ code using the CC builder, including the entrypoint to the program, and the generated impls
    my_build().file("generated.cpp").compile("generated");
    my_build().file("main.cpp").compile("main");
}

In CXX a build script looks very similar, since they both use the CC builder interface:

fn main() {
    cxx_build::bridge("src/main.rs")
        .file("src/example.cc")
        .compile("cxx-example");

    println!("cargo:rerun-if-changed=src/example.cc");
    println!("cargo:rerun-if-changed=include/example.h");
    println!("cargo:rerun-if-changed=include/media.h");
}

Conclusion

As it stands at the minute, CXX definitely has stronger documentation, examples, and adoption, but remains to have strict rules around what gets added, and slow maintenance. Zngur offers a few benefits, but lacks key documentation, references of supported items, or even syntax. It does pose some interesting ideas which could be adopted by CXX, however, such as trait objects, and tagged unions (Rust enums which contain data, for example Option and Result). Although Zngur may be more time-consuming to write due to repeated definitions, we provide a custom prelude which you can place in your project, with any necessary basic types you may want, and this also includes a tool to generate any combination of these that you may want, see our tool zngur-prelude for more.

Some key differences in what is supported are laid out below:

Feature	CXX	Zngur
Generic Support	Limited to built in types (listed below) when trying to define new generic types, e.g. no support for HashMap or Vec<Vec<T>> without a newtype wrapper.	Very broad support for defining Vec<Vec<T>>, HashMap<K, V>, Arc<dyn Trait>, with the caveat that each specialization needs to be defined manually.
Built In Support	CXX has built in support for Vec, String, UniquePtr, &[T] and a few others, and has strong guarantees about them.	Very limited built in support, not even supporting String or bool out of the box, but has very broad support for specifying these types yourself.
Trait Objects	No direct support for Box<dyn Trait>, Docs recommend using UniquePtr instead	Full support: C++ types can implement Rust traits, and trait objects can be passed over the boundary.
Async Support	Partial via cxx-async; integrates with Rust Future including futures crate.	None yet. Can only emulate async via passing boxed function pointers and via channels.
Thread Safety	Enforces Send and Sync requirements via static assertions.	No assertions, but Mutex, Arc are supported.
Build System	Integrated via cxx_build crate to support Cargo, CMake, and Bazel builds. Also has the cxxbridge tool to generate glue code from a file	CLI tool to generate glue code (zngur g file.zng) then manual build. Build scripts are supported but less so, with lesser adoption.
Documentation Status	Mature, comprehensive docs at cxx.rs.	Sparse and incomplete, examples can be found in GitHub but they are limited.
Adoption	Widely used, including in large projects like Chromium and Android.	Early adoption, Adobe seems to have taken an interest.
Overhead	Zero-overhead abstraction, no serialization or copying.	Slight overhead possible; prioritizes flexibility and expressiveness.
Language Definition	Inline within #[cxx::bridge] macro in the main Rust file.	Specified in an IDL file (.zng).
Best Use	Stable, performant FFI, integration with CXX-Qt, projects with simple types at the boundary	Research, quick prototyping, or projects making strong use of Traits and dynamic dispatch in Rust. Easier to integrate into an existing C++ project

Choose CXX if your team needs proven safety, documentation, and tooling integration. Choose Zngur if you’re exploring advanced polymorphism or container-heavy data flows and are comfortable managing ABI stability yourself.

The post Weighing up Zngur and CXX for Rust/C++ Interop 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.

KDAB at Embedded World 2026, Nuremberg, Germany

Editor Team — Tue, 17 Feb 2026 08:08:00 GMT

KDAB at Embedded World 2026, Nuremberg, Germany

At Embedded World 2026, KDAB will showcase how we help customers build robust, high-performance embedded software using Qt, C++, Rust, Slint, and Flutter. From multi-display streaming and real-time 3D UIs to developer tooling and continuous integration on real hardware, our booth will feature hands-on demos that reflect the challenges of embedded systems.

Visit our booth 4-302 to experience the demos live and talk to our engineers about your project.

📍 Nuremberg, Germany
📅 March 10–12, 2026
📍 KDAB Booth: 4-302

Get your tickets here

Migration and Modernization Services

KDAB helps customers transition legacy systems - whether that means moving from Windows CE to Embedded Linux or upgrading an existing software stack. This includes advanced code migration and tooling, as well as setting up complete embedded Linux environments with technologies such as Yocto or Torizon, tailored to the target hardware.

For teams planning the move from Windows CE, there is a brand new guide on migrating to Embedded Linux, outlining key challenges, architecture considerations, and best‑practice workflows in detail. Read it here or pick it up at our booth in Hall 4, Booth 302 at Embedded World.

Beyond Windows Embedded migrations, KDAB offers expertise in a wide range of modernization projects, including Qt 5 to Qt 6 migrations, legacy framework transitions, and broader codebase and platform modernization efforts.

Rugged Controller for ARX Gereon RCS

KDAB Designed and Built a UI for Robotic Platform & Payload Control

UI built using Qt 6 and QML
GStreamer for camera video playback
Controller <-> Robot communication over multiple networks
Oﬄine autonomous mapping support

Live 3D UI for Autonomous Public Transport

Autonomous bus driven by Motor AI infrastructure
Interactive 3D dashboard
Real-time data streamed via MQTT
Touch interface built with Slint

Qt GStreamer Multi-Display Demo

Stream Qt Applications to Multiple Browser Instances

Standard Qt/QML Application on an Intel Atom-based CPU
Complex GStreamer pipeline to transform into a WebRTC stream
Improved the GStreamer plugin
Results viewable in any WebRTC-capable browser
Full touch input and interactivity across multiple screens

DeviceLab for Embedded Hardware

Continuous Integration System on Real Devices

DeviceLab allows for testing Flutter applications on various embedded boards
The Flutter developer experience on embedded is falling short at the moment
To improve the experience, it is necessary to start testing Flutter on embedded hardware
A big improvement would be to integrate some of the most common embedded platforms into the official Flutter DeviceLab

CXX-Qt - Safe Rust Bindings for Qt

Integration for C++ and Rust applications

KDAB supports and maintains CXX-Qt. A set of Rust crates for creating bidirectional Rust ⇄ C++ bindings with Qt. It can be used to integrate Rust into C++ applications via CMake, or to build Rust applications with Cargo.

Watch our YouTube series "Mixing C++ and Rust" to learn more.

Enables Rust and C++ ecosystems to be used in the same application
Allows for idiomatic Rust and C++ code
Integrates easily into existing applications

Developer Tools for Qt, C++, and Linux

Performance Optimization Tools

A selection of useful developer tools for debugging and profiling

GammaRay: High-level introspection tool for Qt applications
KDDockWidgets: KDAB's Dock Widget Framework for Qt
Hotspot: The Linux perf GUI for performance analysis
Clazy Static Code Analyzer: LLVM/Clang-based static analyzer for Qt
Heaptrack: Heap memory profiler and analysis GUI for Linux

Meet KDAB in Hall 4 Booth 302

Visit our booth to see these demos live and talk directly with KDAB engineers about your embedded projects.

Want to meet during the show? Email us at info@kdab.com to arrange a meeting.

Videos from Previous Embedded Worlds

Are you curious what KDAB brought to previous editions of Embedded World? Take a look at this playlist:

The post KDAB at Embedded World 2026, Nuremberg, Germany appeared first on KDAB.

MSVC - Debugging the Static Initialization Order

Thu, 18 Dec 2025 07:48:00 GMT

MSVC - Debugging the Static Initialization Order

Have you ever encountered a bug which is experienced by and also caused by code running before main() even starts? This can happen if you have a static variable or singleton of a class. Each constructor of such classes gets called in order. But what order?

Turns out, this order is undefined by design. And this actually has a name:
Static Initialization Order Fiasco

This mentions code depending on other code. I certainly don't recommend ever intentionally designing an application with such dependencies. But... it can still happen. That's when this knowledge is useful.

How the initialization works

When the program compiles and links, a table of function pointers to all the static methods which need to be called to initialize the static variables is created.
Then, the MainCRTStartup function loops over these pointers and calls them. Again, all this happens before main().

With this background info, we can be more specific in formulating the problem:

One of the constructors of a static variable leaves behind its side effects which leads to code in another constructor crashing.
We can see the outcome where its side effects cause problems in subsequent constructors/static methods.
- But we don't know how many constructors were called before "ours".
- We don't know which of those are causing it.
We need to know this to limit the scope.
The error must be somewhere in there.

What the underlying code looks like

Wouldn't it be great if we could examine the "MainCRTStartup"?

Microsoft actually supplies source code for this! It can be found in the file exe_common.inl which in my case was found at "C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.39.33519\crt\src\vcruntime\exe_common.inl"

The call to _initterm performs this initialization (line 17):

bool has_cbool has_ctor = false;  
__try  
{  
    bool const is_nested = __scrt_acquire_startup_lock();  
  
    if (__scrt_current_native_startup_state == __scrt_native_startup_state::initializing)  
    {  
        __scrt_fastfail(FAST_FAIL_FATAL_APP_EXIT);  
    }  
    else if (__scrt_current_native_startup_state == __scrt_native_startup_state::uninitialized)  
    {  
        __scrt_current_native_startup_state = __scrt_native_startup_state::initializing;  
  
        if (_initterm_e(__xi_a, __xi_z) != 0)  
            return 255;  
  
        _initterm(__xc_a, __xc_z);  // <--- THIS LINE (256)!
  
        __scrt_current_native_startup_state = __scrt_native_startup_state::initialized;  
    }  
    else  
    {  
        has_cctor = true;  
    }  
  
    __scrt_release_startup_lock(is_nested);

Debugging this with x64-debug

Depending on the debugger, this might be out of scope for your IDE. This was the case for me.

Prerequisites

It's assumed you can either use a regular debug build or a release build with generated PDB file (/Zi flag to generate separate PDB for MSVC compiler).

Ensure entry breakpoint is set in the options dialog:

This automatic breakpoint will pause the debugging at the program entry point - not main() but the actual entry point.

Stepping into the program

There is a lot to look at in this screenshot. The program is called gltf_render_pbr. Use the step-into button in the debugger until you reach the correct "file" - it will tell you on the right hand side. Look at the very right for exe_common.inl

Now you can find the correct line for the breakpoint. It is marked in red here. Also notice the __xc_z and __xc_a, those are the start and end pointers of the table where the static initializer function pointers are stored. Note the little red dot to the left of the red highlighted address? That means I have a breakpoint set on that instruction. The call <gltf_render_pbr._initterm> instruction. This is the one jumping into the actual performing code inside ucrtbased.dll.

ucrtbased.dll loop

When you step into that, you will end up here:

This is the loop which calls each initializer in the list.

The actual call into each initialization method is: call qword ptr ds:[7FFCD4B6BBA0].

Set a breakpoint there like I've done in the screenshot above.
Now, from there, step into 2 times more to reach the actual code.
When you've noted where you ended up, just press run and you should get back to the breakpoint. It's inside the loop after all.

Note that the first static method the "pre_cpp_initialization" step in the CRT code, exe_common.inl:216
It initializes exception handlers and other things.

The next call should be into actual C++ initializers. If you have debug symbols, you should be able to see where you end up. In the example program I used - fmt had a static method, and then the next after that was my test code.

When debugging the program next time

When you restart the program in the debugger, each DLL will also have its own CRT startup sequence. Thus:

disable the breakpoint inside the loop in ucrtbased.dll
run until the breakpoint for the _initterm call
re-enable the breakpoint inside the loop in ucrtbased.dll

The post MSVC - Debugging the Static Initialization Order appeared first on KDAB.

Static Assertions in Rust

Thu, 20 Nov 2025 07:58:00 GMT

Static Assertions in Rust

In C++, we have a useful way to ensure certain conditions are met during compilation. This is called static_assert. Here is an oversimplified example, which should always pass:

constexpr int A = 6;

static_assert(A == 6);

In Rust it's not obvious that we have an equivalent for static_assert out of the box. Of course, we have the assert! macro but there's nothing built-in like a static_assert! or the more fitting const_assert! to use. However, with modern Rust, it’s easy to make an equivalent to use in your projects with a small macro.

The macro code is short and sweet, so let's begin by showing it first:

macro_rules! const_assert {
    ($x:expr) => {
        const _: () = ::core::assert!($x);
    };
}

If you haven't come across const in Rust, it has a different meaning than in C++. You can read more about it here but the main difference is that it usually means "compile-time", while in C++ it means "immutable" or "constant". If the Rust compiler can't evaluate it at compile-time, it throws an error.

Now going back to the macro_rules! part, let me explain this super simple example. First, we define a name for the macro - in this case const_assert:

macro_rules! const_assert

Then we want to define how the arguments are matched and parsed. These are called designators, and they are written in the form of $name:type. So in our case, we are defining $x with a type of expr (short for expression.)

($x:expr) => {

Now that we have an expression, we can substitute it in new code. For our case that's putting it in an assert! but in a const context:

const _: () = ::core::assert!($x);

Macros are a huge topic on their own, and our example here is on the easier side. You can read more about how macro_rules! can be used here if you're curious. If you want to test your skills, try modifying the macro to accept other forms of assert!, e.g. to pass a custom error message.

Let's move back to const_assert!, here's the above example but written in Rust:

const A: i32 = 6;

const_assert!(A == 6);

And it's roughly equivalent to writing this manually:

const A: i32 = 6;

const _: () = assert!(A == 6);

In my opinion, though, the intent isn't as clear in the non-macro version. The nice thing about the macro - and the main draw - is that it looks like an assert! which is an existing language construct that you would already be familiar reading.

And similar to static_assert in C++, the macro can be put in the global scope and also in functions:

const A: i32 = 6;

const B: i32 = 5;

const_assert!(B == 6);

fn main() {
    const_assert!(A == 6);

    println!("{A}");
}

I didn’t create this macro, I stumbled across it while researching static assertions to use in CXX-Qt. I was initially going to pick from one of the many choices of static assertion crates, until I looked at their source code and found a lot of them are identical to the macro I showed above. Since macro_rules! are so easy to integrate, it made sense to vendor it instead of adding another dependency.

There was an issue brought forward to the Rust Library team to add something akin to C++'s static_assert into the standard library. The thread goes over some of the limitations with the method shown here as well. Yet they ultimately decided that having an equivalent in the standard library isn't something they want. I'm not sure if I agree with that decision, but, fortunately, it's easy to add your own.

The post Static Assertions in Rust appeared first on KDAB.

Understanding Type-Based Alias Analysis in C and C++

Wed, 22 Oct 2025 10:31:00 GMT

Understanding Type-Based Alias Analysis in C and C++

What are Type Systems?

Type system in statically typed language empowers compilers to identify and reject invalid programs during the type checking phase. Type information associated with different elements of the program (e.g. functions, variables) helps the compiler to detect the state of the program without actually executing the program. While programming language types are frequently employed to detect specific errors during compilation, what is interesting and important is that they serve other purposes as well.

Let’s Talk about Type-based Alias Analysis

Type-based alias analysis is a technique that determines whether two or more pointers or references in a program can potentially point to the same memory address (alias each other, in other words). This analysis mainly relies on the concept of compatible types.

But what exactly are compatible types?

So, aliasing typically occurs between compatible data types. To clarify, data types are deemed compatible when they differ only in attributes like being signed, unsigned, const, or volatile. For instance, both "char" and "unsigned char" are compatible with any other type.

Let’s look at a simple example to understand better:

void modifyValues(int *a, short *b) {
  *a = 42;
  *b = 3;
  *a += 5;
}

Assuming the function call is modifyValues(&n, (short*)&n) here, n might be an integer type.

What would be the resulting value of n?

It depends on the optimization level. Let’s look at the assembly in the case of no optimization level (O0) and its being compiled with clang.

mov rax, qword ptr [rbp - 8]
mov dword ptr [rax], 42  ; *a = 42

mov rax, qword ptr [rbp - 16]
mov word ptr [rax], 3    ; *b = 3

mov rax, qword ptr [rbp - 8]
mov ecx, dword ptr [rax]
add ecx, 5               ; *a += 5;

This is pretty much standard, similar to what we wrote in high-level code - basically a one-to-one mapping. Looking at the assembly, it is clear that there is aliasing, a and b pointing to the exact same location. Hence, the final value for n would be 8 in this case.

Now, let’s compile the program using an optimization level -O2 ,

Take a look at this big assembly:

mov word ptr [rsi], 3
mov dword ptr [rdi], 47

void modifyValues(int *a, short *b) {
  *b = 3;
  *a = 47;
}

In this case, the final value of n would be 47.

Though, is that program right in this case? Obviously, it is not. There is undefined behavior, which is visible through how different optimization levels have different results.

Why is that?

In accordance with the C and C++ standards, when you try to access an object of one type (e.g., int) using an lvalue expression of a different type (e.g., short in a function argument), and these types are not considered compatible (except for specific exceptions outlined in the standards), it leads to undefined behavior. This means that the program's behavior cannot be predicted or relied upon, and it may produce unexpected results.

Personally speaking, I really like when undefined behavior teaches much more about programming than the defined behavior. :)

TBAA in Action:

Consider the following example:

void Foo(float *v, int *n) {
  for (int i = 0; i < *n; i++)
    v[i] += 1.0f;
}

In this case, the compiler and TBAA ensure that the types are not compatible and memory lookup for *n can be optimized by performing it just once. The resulting value can be stored in a register, which is then accessed in each iteration of the loop. This optimization helps reduce memory access overhead and can lead to improved performance.

Now, consider this example:

void Foo(float v[], float *c, int n) {
  for (int i = 0; i < n; i++)
    v[i] = *c + 1.0f;
}

In the provided example, the types of v and c are compatible, which leads the compiler to assume they may alias, meaning they could refer to the same memory location. Consequently, the compiler takes measures to ensure that fetching the value of *c within the loop will indeed be performed in each iteration. This behavior is implemented to guarantee that the value pointed to by c is fetched afresh in every iteration of the loop. However, it's important to note that this meticulous handling, while beneficial for correctness, can potentially impact performance.

For More Details Let's Look at their Assembly

First Version (Non-compatible types):

Foo(float*, int*):
    movsx rax, DWORD PTR [rsi]
    test eax, eax
    jle .L1
    movss xmm1, DWORD PTR .LC0[rip]
    lea rax, [rdi+rax*4]
.L3:
    movss xmm0, DWORD PTR [rdi]
    add rdi, 4
    addss xmm0, xmm1
    movss DWORD PTR [rdi-4], xmm0
    cmp rdi, rax
    jne .L3
.L1:
    ret

Second Version (Compatible types):

Foo(float*, float*, int):
    test edx, edx
    jle .L1
    movsx rdx, edx
    movss xmm1, DWORD PTR .LC0[rip]
    lea rax, [rdi+rdx*4]
.L3:
    movss xmm0, DWORD PTR [rsi]
    add rdi, 4
    addss xmm0, xmm1
    movss DWORD PTR [rdi-4], xmm0
    cmp rdi, rax
    jne .L3

In the first version (Foo(float*, int*)), the loop counter n is passed as a pointer to an integer (int*). The code loads this integer value (*n) into a register (rax) before entering the loop, and then uses this register for loop control.

movsx rax, DWORD PTR [rsi]

This means that the loop counter is loaded from memory once at the beginning of the loop, and the register value is used throughout the loop iterations.

In the second version in each iteration of the loop, *c is loaded into xmm0.

movss xmm0, DWORD PTR [rsi]

This behavior ensures that the value pointed to by *c is consistent throughout the loop iterations.

Have you noticed how type-based alias analysis benefits compilers to take optimizations action?

But the question remains:
What is an explicit fix for this, or hint to the compiler that there is no chance of aliasing even in the case of compatible types?

In C, the restrict keyword comes to the rescue when you want to explicitly inform the compiler that there is no chance of aliasing between pointers.

Consider this example:

void Foo(float* restrict v, float* c, int n) {
  for (int i = 0; i < n; i++)
    v[i] = *c + 1.0f;
}

In practice, you may need to declare both pointers as restrict if you can guarantee that they don't alias each other.

Let's Look at the Assembly for the Above Code:

Foo:
test edx, edx
jle .L1
movsx rdx, edx
movss xmm0, DWORD PTR .LC0[rip]
lea rax, [rdi+rdx*4]
and edx, 1
je .L3
movss DWORD PTR [rdi], xmm0
add rdi, 4
and edx, 1
je .L11
.L3:
movss DWORD PTR [rdi], xmm0
add rdi, 8
movss DWORD PTR [rdi-4], xmm0
cmp rdi, rax
je .L11

See how it impacted the performance:

movss xmm0, DWORD PTR .LC0[rip]  ; Load 1.0f into xmm0
addss xmm0, DWORD PTR [rsi]      ; Add *c to xmm0

The movss instruction loads the constant 1.0f into xmm0, and then addss adds the value pointed to by c to xmm0. Importantly, c is loaded into xmm0 only once outside the loop and re-used in the loop. Using the restrict keyword, you provide the compiler with the assurance that the memory regions accessed through the pointers v and c do not overlap. The compiler can then optimize the code more aggressively for performance.

However, a word of caution: you must be very careful when using restrict, as the compiler won't warn you about its incorrect use.

Interestingly, the restrict keyword is not a part of C++. Why is that?

The history behind this decision is quite intriguing. When reviewing C99 features for inclusion in C++, there was consideration of adding restrict. However, no paper proposal was made at the time. Hence, it didn't make its way into C++.

restrict was originally designed for fine-grain aliasing in C but may not be well-suited for the type-based aliasing that is more common in C++. In C++, pointers are less prevalent in class abstractions and restrict may not align well with the C++ language design.

In summary, the restrict keyword in C and type-based alias analysis are tools that help compilers generate efficient and optimized code while maintaining program correctness and adherence to language standards.

Thank you for reading!

The post Understanding Type-Based Alias Analysis in C and C++ appeared first on KDAB.

KDAB at Embedded World NA 2025

Editor Team — Tue, 21 Oct 2025 06:51:00 GMT

KDAB at Embedded World NA 2025

KDAB will be exhibiting at Embedded World North America from November 4th through 6th, 2025, in Anaheim, California.

Event Details:

📍 Anaheim, California
📅 November 4–6, 2025
📍 KDAB Booth: 5039

Get your tickets here

Explore KDAB Demos

Live 3D UI for Autonomous Public Transport

The UI displays the autonomous driver's real-time awareness and planned actions to the vehicle users.

Autonomous bus driven by Motor AI infrastructure
Interactive 3D dashboard powered by Serenity
Real-time data streamed via MQTT
Touch interface built with Slint

Qt GStreamer Multi-Display

Stream Qt applications to Multiple Browser Instances

Standard Qt/QML Application on an Intel Atom-based CPU
Complex GStreamer pipeline to transform into a WebRTC stream
Results viewable in any WebRTC-capable browser
Full touch input and interactivity across multiple screens

Medical tool for interventional cardiac imaging

LUMA Vision and KDAB developed a fully software-defined, end-to-end imaging system that could adapt to market and clinical needs.

Uses Qt3D/Vulkan for visualisation of ultrasound data
Uses QML for 2D user interface
CUDA-based 3D data processing

Performance optimization tools

For developers using Qt, C++, and Linux

GammaRay: High-level introspection tool for Qt applications
Hotspot: The Linux perf GUI for performance analysis
KDDockWidgets: KDAB's Dock Widget Framework for Qt
Clazy Static Code Analyzer: LLVM/Clang-based static analyzer for Qt
Heaptrack: Heap memory profiler and analysis GUI for Linux

Meet KDAB Engineers

Let's discuss your specific C++, Qt, Rust, and 3D development challenges. Visit KDAB in booth 5039.

We look forward to connecting with you in Anaheim!

The post KDAB at Embedded World NA 2025 appeared first on KDAB.

GammaRay 3.3 Released

Editor Team — Mon, 20 Oct 2025 13:19:00 GMT

GammaRay 3.3 Released

GammaRay 3.3 is now available.

GammaRay is a tool for developers working with the Qt framework, offering deep inspection capabilities that help you analyze, debug, and understand your applications at runtime. It provides insight into the behavior and state of Qt objects while the application is running, allowing for efficient troubleshooting, performance tuning, and exploration of complex UI or logic issues.

What’s new in GammaRay 3.3

Version 3.3 introduces several updates aimed at maintaining compatibility with current Qt versions and improving stability across platforms.

GammaRay has dropped support for Qt 5, with the minimum supported version now set to Qt 6.5. For developers who still rely on Qt 5, the 3.2 branch will continue to receive maintenance releases where necessary, including critical bug fixes and backports. This transition allows GammaRay to focus on modern Qt capabilities and simplifies ongoing development.

On Windows, support for LLVM MinGW has been added, expanding the range of supported toolchains. A long-standing issue where the GammaRay user interface would occasionally fail to appear on Windows has also been resolved.

Additional improvements include updating the LZ4 compression library to version 1.10.0 and fixing build compatibility with Qt 6.10, ensuring GammaRay continues to integrate smoothly with the latest Qt releases.

You can find the full list of changes and downloads for this release on GitHub.

We look forward to feedback from users as they integrate GammaRay 3.3 into their workflows and encourage those still on older Qt versions to follow the 3.2 branch for continued support.

Videos about GammaRay

GammaRay Tutorials: https://www.youtube.com/playlist?list=PL6CJYn40gN6itybeSJb5FvRWOxVW5PCUX
GammaRay Tutorials for Qt Widgets Applications: https://www.youtube.com/playlist?list=PL6CJYn40gN6izGNDIH06YXf0UzR_1BVhn
More info on GammaRay: https://www.kdab.com/software-technologies/developer-tools/gammaray/

The post GammaRay 3.3 Released appeared first on KDAB.

CI/CD Simplified: Comparing Buildbot, Jenkins, and GitHub Actions

Jan Marker — Wed, 15 Oct 2025 07:24:59 GMT

CI/CD Simplified: Comparing Buildbot, Jenkins, and GitHub Actions

If you’re setting up a CI/CD pipeline, choosing the right tool is a big decision – a good CI system can save time, catch bugs early, and make deployments less stressful. But with so many options out there, figuring out what works best for your team can be overwhelming. In this post, I’ll break down three of the most popular CI/CD tools – Buildbot, Jenkins, and GitHub Actions (GHA) – and share some tips on making them work for you. I’ll also talk about a couple of helper tools that can make your CI workflow even smoother.

CI/CD tools vary widely in features and approaches, but at their core, the biggest distinctions boil down to two considerations:

Should CI maintenance be concentrated in a dedicated team or distributed among all developers in the project?
Does your team prefer a self-managed solution or a fully-hosted cloud service?

Answering these questions and understanding how they affect your workflows can help you choose a tool with the right balance between control, flexibility, needed expertise, and ease of maintenance.

Buildbot: Centralized and customizable

Buildbot is an on-prem CI tool known for its centralized architecture, where all configurations and processes are managed in one place. It’s popular with teams that have similar workflows across multiple projects. Projects like Python, Blender, and LLVM use Buildbot to handle builds efficiently. Its centralized setup makes it easy to implement global changes, such as adding new tools or updating validation rules, with minimal disruption across all projects.

However, this centralized control comes with a trade-off: Substantial maintenance effort. You’ll likely need a dedicated administrator – especially as projects grow. Buildbot lacks a user-friendly interface, so you need to edit Python scripts and config files to make changes. And, for teams working with external clients or diverse user groups, it doesn’t separate users or projects into clean access groups.

Still, if you’ve got many similar projects with shared workflows and dependencies that need deep customization, Buildbot is an excellent choice, particularly for teams that have the resources to maintain it.

Jenkins: Flexible and developer friendly

Jenkins takes a different approach. It’s also an on-prem solution but with a more distributed approach to CI workflows. Unlike Buildbot, Jenkins allows teams to manage CI configurations, including builds and workflows, right in their own project repositories. This decentralized design makes it a strong fit for teams with diverse projects, tools, or languages that want to customize builds on a per-project basis.

Jenkins is relatively easy to set up and use, thanks to its web-based interface for managing builds and configurations and its plug-in ecosystem that covers many common use cases. That said, this flexibility comes at a cost: Making global changes across projects can be more difficult in a decentralized setup, and certain customizations require Groovy scripting, which is less straightforward than Python.

Jenkins shines in environments with many unique workflows and tools, and its SaaS-like features, such as user and project management, make it a good choice for multi-client or collaborative teams. While a dedicated administrator isn’t always necessary for basic use cases, scaling and complex configurations benefit from having someone knowledgeable in Jenkins at the helm.

GitHub Actions: Cloud and easy

GitHub Actions (GHA) is a cloud-based CI/CD solution tightly integrated into the GitHub platform. Designed for simplicity, GHA provides pre-configured environments and scripts for common CI/CD tasks, making it easy for teams to get started. GHA is especially great for open-source projects, because it’s free for public repositories and requires no infrastructure maintenance.

However, the platform is not without its limitations. Since GHA is tied exclusively to GitHub, it’s a no-go if you’re not on GitHub. And for private repositories, you’ll have to pay once you use up your free minutes, making it less appealing for budget-conscious projects. It’s also not as flexible as Jenkins or Buildbot for teams that need heavy customization or an on-prem solution.

GHA is best for open-source teams or small projects already using GitHub. It’s also an excellent option for CI/CD beginners who want a streamlined, maintenance-free solution. For private projects with complex needs or teams that need platform flexibility, other tools like Buildbot or Jenkins might be a better fit.

CI helpers: CMake presets and pre-commit

Even with a good CI/CD system, there are a couple of tools I’d recommend to make life easier. Helper tools like CMake Presets and pre-commit can significantly streamline workflows, particularly for desktop and embedded development.

CMake Presets is an extension of the popular CMake build tool that simplifies managing multiple build configurations. By letting you define specific presets for tasks such as local-development or CI builds, CMake Presets cleanly separates these processes, reducing complexity in large projects where environments and dependencies are shared across different workflows.

Similarly, pre-commit is a framework for managing Git pre-commit hooks, and it’s a game-changer for catching issues early. You can use it to run static analysis, enforce code formatting, and check for common errors before any files are committed. And because it runs locally, it reduces the load on your CI systems and gives developers quick feedback, improving code quality and speeding up reviews.

So, which tool is best for you?

The best CI/CD solution depends on your team’s needs and workflow complexity. Buildbot is great if you’ve got a lot of similar projects and want full control over your CI pipeline. Jenkins is better if you’re juggling a mix of projects and need something flexible and easy to manage. And if you’re already on GitHub, GitHub Actions is the fastest way to get up and running.

No matter which tool you choose, pairing it with helpers like CMake Presets and pre-commit can make your workflows even better. At the end of the day, the best CI/CD setup is the one that fits your projects, your team, and the way you like to work.

For a deeper dive into these topics and more advice on setting up your CI/CD pipeline, take a look at our CI/CD Best Practice whitepaper.

The post CI/CD Simplified: Comparing Buildbot, Jenkins, and GitHub Actions appeared first on KDAB.