Qt: An embedded developer’s perspective

Welcome to the second part of our blog on the pros and cons of Qt for embedded systems. In the first part, Bluefruit founder Paul Massey discussed why Qt is a compelling GUI framework from a business (and Agile) perspective. In this blog, Senior Developer Ben Watts-Jones urges careful consideration before using Qt and warns of possible pitfalls teams might encounter.

But first…

Before we get started, it’s important to acknowledge the bias of this blog.

At Bluefruit, we develop software for (or to integrate with) embedded systems. We heavily rely on libraries written in system-level languages like C++ to achieve the fine control necessary for optimal system/hardware integration and performance. As a result, robust, safe, and reliable operations are paramount concerns for our applications. We don’t generally have a need for complex animations or 3D graphics. However, a relatively modern user interface, exceeding the capabilities of more basic bare-metal frameworks, is often desirable. This is why we might consider Qt.

Some developers working on different projects may see no value in Qt at all, while others might see more. 

With that out of the way, let’s begin.

Don’t use Qt for everything 

Don’t get locked in 

Consider your testing 

Collaborate early 

Mileage may vary 

Should I use Qt for my project?

There’s no denying that Qt has its advantages for embedded software development. It offers a reasonable amount of cross-platform compatibility, performance, and GUI capabilities. Developers are familiar with Qt, and it can be ported to various systems, including embedded Linux. 

It’s easy to see why people like it.

However, there are some important development considerations that must be made before you rush into using it. Firstly… 

Don’t use Qt for everything 

The promise of a single codebase that works across platforms can be tempting, especially for stakeholders on the business side. After all, why create code for each individual platform when you could just have one? There are several good reasons. 

For instance, utilising Qt/C++’s ability to compile to WebAssembly, which can be run by web browsers, you could use Qt to build a website… but this approach would sacrifice the advantages of leveraging standard web technologies and browser functionalities considerably. The same goes for mobile applications. 

Documentation becomes more complicated, too. For example, when building an iOS app with SwiftUI, one of Apple’s recommended native frameworks, you’ll utilise Apple’s own documentation. With Qt using its own abstractions, you’ll need to understand how these approaches work together. 

Shoehorning a project into a single codebase for all platforms can lead to a bloated, complex application that’s more difficult to debug and maintain on each specific platform it targets. In the end, the cost of maintaining a single, non-native codebase might outweigh the benefits of code reuse. The key is to carefully consider the trade-offs between code reusability and platform-specific optimisation to find the most efficient and effective development approach for each project.  

Don’t get locked in 

From a software architecture standpoint, deciding whether to use Qt is a minor detail; it certainly shouldn’t be your first question. Primarily, you want a modular codebase with clean dependencies. 

The problem is this: You want to build an application that uses Qt, but Qt wants you to build a Qt application. There is a huge range of Qt modules that will do everything under the sun, but they’re also a means to increase your dependency on the framework and make it more difficult to move away. 

Keep them separated 

Ideally, you want a thin GUI layer that interacts with your business logic through a well-defined interface. This interface allows for easier porting of your codebase to different frameworks in the future and improved unit testing of your business logic without relying on specific UI implementations. 

While there must be room for some pragmatism, the interface should ultimately prioritise what’s most convenient for your business logic. Qt should adapt to your needs, not the other way around. 

By achieving a clean separation, you gain flexibility. You have the freedom to experiment with or even replace Qt later without significant rework. More importantly, your core business logic remains isolated and testable, ensuring its quality and maintainability. 

In short: Qt should serve as a tool for the business logic, not the other way around. 

Consider your testing

While Qt offers testing frameworks such as ‘Squish, their effectiveness depends on what you’re testing. They might be testing Qt’s implementation details rather than the actual GUI behaviour. 

If you’ve kept your Qt layer thin and dependent on your business logic, as previously discussed, most of your application logic will be well-tested independently of the GUI framework. 

For GUI-specific testing, consider end-to-end testing strategies. You can simulate the application details to the extent required. For example, if the GUI is running on an embedded device, you may want to simulate the rest of the device. You could use OCR (Optical Character Recognition) to verify on-screen text changes after user interactions. This approach offers meaningful testing but can be brittle due to potential OCR errors or unexpected UI changes. 

If the Qt app is a desktop application that communicates with an embedded device over, say, USB or a network, you may want to mock just before that communication layer to mimic the desired states of the expected connected device.  

Ultimately, there’s no perfect solution for GUI testing. Each method has its drawbacks. However, Qt does acknowledge the importance of testability compared to some frameworks that completely disregard it.

Collaborate early 

Moreso than in front-end web development, Qt’s capabilities for responsive and accessible design require careful upfront planning. Retrofitting these features later becomes a significant challenge. 

Imagine you need to increase text size or translate to a different language with longer words. Where web design grants a high degree of flexibility, with scroll bars and scaling elements, Qt does not work that way by default. Increasing font size for accessibility or word length for localisation could lead to elements overflowing and/or overlapping. 

The key here is early collaboration: 

Designers: Designs need to consider various text sizes, languages, and screen layouts from the beginning. 

Developers: Development should account for responsive behaviour during implementation as well as performance impact, which can be surprising with Qt. 

Business stakeholders: User stories should incorporate the importance of responsive design and accessibility to ensure business buy-in. 

This collaborative approach helps avoid the trap of “pushing forward”, where initial designs appear functional but lack the flexibility for different user needs.

Mileage may vary 

Qt could present a compelling option for embedded developers working on certain projects. However, it’s crucial to remember that it is just a tool, not the defining factor of your project.  

Prioritise a well-designed, modular architecture with clean dependencies to ensure flexibility and long-term maintainability. Focus on core business logic first, embracing collaboration and upfront planning for responsive design and accessibility. By using Qt strategically, you can create user-friendly applications that excel across platforms. 

Should I use Qt for my project? 

Whether you should use Qt—or any other framework—ultimately depends on your specific project needs. The ever-evolving landscape of software development, including licensing models, functionalities, and competitor offerings, necessitates a tailored approach. 

When embarking on a new project with GUI requirements, take the time to re-evaluate all available options. Consider factors like project scope, resource constraints, and business goals to make an informed decision. By understanding Qt’s core principles and staying up-to-date with the evolving development landscape, you’ll be well-equipped to choose the right GUI toolkit for your next project.