Woboq Code Browser: under the hood

A few years ago, I was introducing the code browser and code.woboq.org

Since the then, we implemented a few new features and made the source code available, which you can browse from the code browser itself.

In this article, I give more technical information on how this is all done.

What/Why a code browser?

As a developer, I spend more time reading code than writing, and I found reading code online a rather poor experience. Hence, I made a way to publish code in a way that can be read just like in a good IDE, with links, tooltips, and semantic highlighting. Read more about it in the original blog post.

Architecture Overview

The idea is that there is a generator that generates all the .html pages ahead of time. This is a bit like a compilation. In the process we also fill up a database containing all the symbols and where they are defined or used, as well as other information such as the documentation.

The database

Because NoSQL is trendy, we use a well-known NoSQL database directly included in the kernel: the file system ☺. There is a huge directory containing one file per global symbol. Each file contains all the information you see in the tooltip. The type of the variable, the list of its uses and its documentation. The HTML files has tags referencing the symbol, the JavaScript can then do an AJAX request on that file in order to render the tooltip contents.

For example, the file for QQmlEngine::removeImageProvider , looks like this:

<dec f='qtdeclarative/src/qml/qml/qqmlengine.h' l='132' type='void QQmlEngine::removeImageProvider(const QString &amp; id)'/>
<def f='qtdeclarative/src/qml/qml/qqmlengine.cpp' l='1209' type='void QQmlEngine::removeImageProvider(const QString &amp; providerId)'/>
<doc f='qtdeclarative/src/qml/qml/qqmlengine.cpp' l='1204'>/*!
  Removes the image provider for \a providerId.

  \sa addImageProvider(), QQuickImageProvider
<use f='qtdeclarative/tests/auto/quick/qquickimageprovider/tst_qquickimageprovider.cpp' l='360' u='c' c='_ZN23tst_qquickimageprovider14removeProviderEv'/>
<use f='qtdeclarative/tests/auto/quick/qquickimageprovider/tst_qquickimageprovider.cpp' l='389' u='c' c='_ZN23tst_qquickimageprovider15imageProviderIdEv'/>

You can see that there is one entry for the declaration, the definition, the documentation, and one for each usage. This is the information displayed in the tooltip.
We also store information about inherited classes or methods.
See the symbol page that shows information from the tooltip and more.

This way, the whole generated browsable code is just a set of files that can be served by any simple web server. The whole thing is maybe three times as big as the original source code. Which still amounts to several GB when we host so much source code. However, it is highly compressible. To save space and ease upload, we use squashfs images. That way we even have atomic updates ☺

Using Clang to parse C/C++

Here is the interesting part: how is the generator working?

Clang is more than just a compiler, it is really a library to parse C and C++.

Clang provides all the tools required, all I have to do is to create an clang::ASTConsumer. Once the parser has finished its job, we can then visit the full AST of the translation unit with the clang::RecursiveASTVisitor. As explained in this tutorial.

We then visit all the declarations and usage nodes. We know the source location of the node, so we know if we are in a file that we should generate. In particular, we do not generate header files twice, so if the header file has already been parsed, we ignore that node. Knowing the location of the node, we can register a HTML tag for it. We give a data-ref tag with the mangled name of the symbol so the JavaScript will be able to show the tooltip, and we give proper classes so it can be semantically styled. We also register the use in the database.

Macro Expansions

We also show the expansion of a macro in the macro tooltip. Macros does not appear as node in the AST because they are expanded before, in the pre-processing phase. We use clang::PPCallback to be notified each time a macro is expended. Unfortunately, getting the actual expansion is far from easy since the expansion never appears as such in memory. What happens is that the pre-processor just provides tokens to the parser. We have to pre-process again the macro and write the token strings in to tooltip.

Documentation Comments

Comments are ignored by the parser so they are not part of the AST. We do another pass in which, for each file, in which we find comments and keywords for the basic syntax coloration of things that are not in the AST, and color these element appropriately. We will try to associate the comments with the closest declaration or definition, so it can go in the database (in the tooltip). We also recognize some doxygen commands such as \fn which associate the comment with a different declaration.


We detect a few Qt extensions. We recognize calls to QObject::connect, QMetaObject::activate and similar call like QTimer::singleShot (See the full list of recognized functions). Since SIGNAL and SLOT are macros that transform their argument to string, we can easily extract the string literal and parse that in order to find to what method it is. We know in which class to look because know the type of the QObject sub class of the receiver parameter.

Usage classification

When looking at the AST, we see how the variables are used. We can classify if the variable was simply read, or modified. We add a little letter in the uses in the tooltip. If you click on the little 🔗 icon in the top-right of the tooltip you can filter by type of usage.

Similarly, we see when arguments are passed by references, and we annotate the source code with little &. We also annotate the code with little when there is an implicit call to a constructor or conversion operator.

Clang Tooling

The clang tooling needs to interface with the build system to know the list of compilation commands. (The flags passed to the compiler such as the include paths, the defines, or other languages options).
All the commands are in a compilation database hold in a compile_commands.json file. If one use cmake as a build system, it is trivial to generate this list of command by passing -DCMAKE_EXPORT_COMPILE_COMMANDS=ON. Ninja also can export the compile_commands. But with others build system it is a bit more complicated. With some build system such as qmake, we parse the output of make -n. When that is not supported, there is a script used as a proxy compiler that records the compilation commands.

Find out more about this in the README.

Javascript Code

Once the static HTML and the database have been generated, the rest of the logic happens client side. The server is simply serving static files. The Javascript code runs in the browser will fetch these files and enable all the features such as the tooltip or the search.

Search for a file or function

In order to find a file, the browser will first download, via AJAX, a file containing the list of all the files for this project. For the functions, a file containing all the functions would be too big. We therefore split the functions in several files starting with the first two letters of the function. So when someone starts typing "Parse", the file fnSearch/pa (pa being the first two letters) gets downloaded to find matches in there.


This was explaining how code.woboq.org works. Get it for your own code!

Qt World Summit 2016 Conference App – Open Source & Live Now!

The Qt World Summit 2016 will take place in San Francisco, USA from October 18-20. A great tech conference like this deserves a great conference app, that’s why we built one!

You can now download the app for iOS & Android:

App Store Google_Play_Badge-1


The app was fully built with QML and V-Play Apps, which allows a native UI and user experience across both platforms, with just a single source code:


The Qt World Summit Conference app highlights several of the key benefits of the V-Play Apps SDK:

  • Native UI & UX for iOS & Android
    • Navigation drawer on Android, swie-back navigation and tab bar on iOS
    • Native page transitions
    • Native Android style: Material design & ripple effects
    • Native iOS style: list views, list items, buttons,
  • Single Code Base, 100% code reuse cross-platform, no platform-specific code!
  • Gamification elements: add a talk to your agenda and rise in the leaderboard
  • Chat with other conference attendees

You can even simulate iOS & Android styles within the app! Just go to Settings and toggle between the 2 native platform styles.

Get the Open Source Conference App

Best of all, we’ve made this app open-source on Github so you can use it as a starting point for your own app. Or re-use the code to create your own conference app for upcoming events.


Here is a quick overview of what you can do with the Qt World Summit conference app:

For a full reference of the V-Play Apps API, see here.

We will also show how we developed this app in a session at the Qt World Summit! If you attend the conference, make sure to watch our presentation. :)

The post Qt World Summit 2016 Conference App – Open Source & Live Now! appeared first on V-Play Engine.

Qt 5.6.2 Released

I am please to inform that Qt 5.6.2 has been released today. This is the second patch release to the long-term supported Qt 5.6, and there will still be more patch releases to come. While a patch release does not bring new features, it contains security fixes, error corrections and general improvements.

The Qt 5.6.2 patch release continues the quality and maturity focus of Qt 5.6, bringing close to 900 improvements on top of the already solid Qt 5.6.1 release. These bug fixes and improvements are also available in the later releases of Qt including the upcoming Qt 5.7.1 and 5.8.0 releases. Qt 5.6.2 is well suited for users that can not upgrade to a later version of Qt, for example due to dependency to C++98 compiler.

For details of the most important improvements and bug fixes in Qt 5.6.2, please check the change logs for each module.

If you are using the online installer, Qt 5.6.2 can be updated using the maintenance tool. Offline packages are available for commercial users in the Qt Account portal and at the qt.io Download page for open-source users.

The post Qt 5.6.2 Released appeared first on Qt Blog.

Make It Magic – User Experience and the Internet of Things

by Josh Clark, UX Strategist & Founder, Big Medium (Qt Blog)

Our interfaces are leaping off screens and onto our bodies, into our living rooms, and steadily into the most intimate spaces of our lives. There’s huge opportunity here, but also significant risk. Will the technology bend to our lives, or will it be the reverse?

With a word or a gesture, we’re now able to summon invisible forces to do our bidding. Back in the day, they called these spells. Today, we call them user interfaces and digital systems. Somehow, though, we’ve lost something essential in that shift from fantasy to science fiction.

As technologists, we tend to be overly enamored of our technology. For us, the device too often becomes the end goal, and we lose track of the genuine human need that we might otherwise meet. We talk about “technology solutions” but lose track of the problem we’re trying to solve (or we create entirely new ones). A subtle shift in perspective will help us build the right things: let’s stop aiming to invent science fiction and start making magic instead.

Centuries of myth and legend have given us the design patterns for what happens when we light up everyday objects with magical powers: magic mirrors, shoes, rings, cloaks, food, you name it. We finally have the science to actually do it, but we haven’t connected these emerging products back to these timeless stories—and to what they tell us about human wants and needs.

The best kind of magic makes an object even more of what it already is: a bag that can hold an impossible amount, eyeglasses that can see anywhere, a flute that plays irresistible music. The appeal of the story is not in the materials or the enabling technology, but how the magic amplifies what we most want or love about the object itself (and often, ourselves).

How can we bring the same approach to the smart home? How can we use technology not to “disrupt” the home, but to make it _more_ of the home we already love? How can technology help to reinforce the home as a calm oasis, a place to connect with family and friends? Connected isn’t always smart, and smart isn’t always good. We have to meet a real human need. Let’s do more than just make things talk; let’s improve the conversation.

In my Qt World Summit talk, Magical UX and the Internet of Things, I’ll share the perspective I’ve been applying to my product work lately. I no longer look at the tech around me and ask, “what can I build with this technology” or “what if I strap these sensors and processors onto your body?” Instead, I’ve started looking at everyday objects and asking questions like, “what if these glasses (or this mirror, or this ring) were magic?” Changing that starting question has led my design work down a very different product path, less focused on engineering and technology, and more on basic human wants and desires.

My product work has turned asthma inhalers into protective talismans and watches into magic amulets. In the end, they’re still enabled by familiar technology, but they’re animated by a design approach that builds on existing behaviors and contexts—and essential human needs.

New kinds of interfaces require new kinds of thinking. Starting from a place of magic gives us permission as designers and engineers to let go of old, screen-based habits, and create things that genuinely delight and amaze.

I hope to see you in San Francisco at Qt World Summit 2016 — Register now.


The post Make It Magic – User Experience and the Internet of Things appeared first on Qt Blog.

Qt Quick Controls 2.1 and Beyond

As most of you already know, Qt Quick Controls allow you to save time developing user interfaces by utilizing a library of ready-made controls with different styles which you also can easily customize to your liking. The Qt Quick Controls 2 module delivers the next generation UI controls with a great performance boost.

The feature freeze of Qt 5.8 was a while back, and the 5.8 beta release is being prepared as we speak. Let’s take a brief look at what’s coming in Qt Quick Controls 2.1 in Qt 5.8.

In the first release of Qt Quick Controls 2, we made a deliberate choice to focus on the areas that the first generation Qt Quick Controls were not able to serve well: embedded and mobile. The next release introduces a few features that improve the behavior of the new controls on traditional desktop platforms.

Hover Effects

Hover effects have been one of the most popular feature requests. We have had the enablers already in place, meaning that it has been possible to implement hover effects for your own custom controls and styles, but the hover effects for the built-in styles did not make it to the first release. I’m happy to announce that the Material and Universal styles have gained hover effects in Qt 5.8. This alone makes the controls more pleasant to use on platforms with a mouse pointer. Check the following video to see how the Universal style hover effects look.

Ripple Effects

While working on the hover effects, it became apparent that we would also like to have ripple effects for the Material style. Take a look at the following screencast to see what we have cooked up.

System Theme

We have also introduced a new theme option for the Material and Universal styles. The new theme is called System, and it simply resolves to either the light or dark theme based on the system theme colors. This feature is opt-in, because it typically takes some extra consideration to make applications look good in both light and dark themes. For example, if you use icons in your application, you may have to ship both light and dark versions.

Platform Types

Another thing we have been working on is a new module that provides a set of experimental “platform” types. These QML types are light-weight wrappers for the native menu, menubar, standard dialog, and system tray icon implementations provided by the Qt Platform Abstraction layer. For the time being, since not all platforms have implementations of all of these native types in place, Qt Widgets are used as a fallback when a native implementation is not available. The platform types integrate seamlessly with Qt Quick, but unlike the heavily customizable Qt Quick Controls, the platform types are not customizable using Qt Quick primitives. Inspired by the good old example by the same name in Qt Quick Controls 1, we have implemented a new Text Editor example that offers a modernized look’n’feel and showcases the platform types.

Qt Quick Controls 2 - Text Editor example (Desktop UI)

New Controls

There are a few new QML types in the core Qt Quick Controls 2 offering too. While we were implementing the Text Editor example, we realized that it would be nice to have ready-made separators that play nice with the built-in styles and themes. We ended up introducing MenuSeparator and ToolSeparator, that are designed to be used in Menu and ToolBar, respectively.

We have also added a new Dialog popup that offers the same convenient “header-content-footer” layout found in ApplicationWindow and Page. Dialog uses DialogButtonBox, which is also offered as a standalone type, to let you configure a set of standard buttons in a breeze.

Qt Quick Controls 2 - Dialogs

Last but not least, our latest family member is RoundButton. Customizing Button to have a round background was a popular question on various forums. Even though it is straight-forward to customize the background, it means losing the default background, which looks different for different styles. We decided to offer a control that does this out of the box. The Material style version of RoundButton supports elevation, so it can be easily used to create a Floating Action Button. We have used RoundButton in the touch UI of the Text Editor example for triggering the edit mode.

Qt Quick Controls 2 - Text Editor example (Touch UI)

What’s Next?

Qt Quick Controls 2 already offers many features Qt Quick Controls 1 never had, but there are still a few smaller and larger features that are, in comparison to the old set, still missing from the new controls. We don’t have an exact time schedule to offer for each feature, but we’ll continue catching up with the rest, version by version. For example, editable ComboBox is something that we have already started working on, and if everything goes well, it is going to be introduced in Qt Quick Controls 2.2 in Qt 5.9. Some notable missing features from Qt Quick Controls 1 are Action, SplitView, TableView, and TreeView.

Other items on the wish-list are Pickers, SegmentedButton, persistent Drawer, floating/transient headers and footers, action bar, pull-to-refresh, multi-touch support, perhaps some new styles… well, a lot of things. We won’t run out of ideas for a while. :) If you have some other great ideas, please don’t hesitate to send us a suggestion!

In other news, Mitch and I are delivering an online presentation about Qt Quick Controls 2.1 on October 11th. Register for the webinar today to learn more!

At the Qt World Summit, there will be two presentations related to Qt Quick Controls 2. Shawn will be talking about developing user interfaces with Qt Quick Controls 2, and Ekke is going to present how he built the Qt World Summit Conference App using Qt Quick Controls 2.

The post Qt Quick Controls 2.1 and Beyond appeared first on Qt Blog.

Qt World Summit 2016 – Meet You in San Francisco!

The Qt World Summit 2016 will take place in San Francisco, USA from October 19-20. The V-Play team will be in attendance for the world’s largest gathering of Qt developers. Want to meet us there for a chat about cross-platform mobile game or app development at the summit? Or on October 18th or 21st in the Bay Area? Just let us know when to meet you!

Meet Us in San Francisco!

What to Expect at the Qt World Summit 2016?

The Qt World Summit is one of the most important events of the year for cross-platform developers. It gives you the chance to look back over a year’s worth of innovation and get a glimpse at the future of Qt development all in one place.

The World Summit is also the place to be for the best presentations, attending lightning talks and you can rub shoulders with the world’s best Qt developers.

V-Play at the Qt World Summit

The V-Play team will be in San Francisco from October 18-21 and V-Play CEO, Christian Feldbacher, will be giving a presentation at the Qt World Summit.

Christian’s presentation, “How to Develop with Qt for Multiple Screen Resolutions and Multiple Platforms and Best Practices for an Efficient App Lifecycle with Qt” will take place on Thursday, October 20 at 2.00pm.

The first part of this presentation will show you how to use a single codebase while having native-looking UIs & UX across a range of platforms. The second part will show you how you can use Qt in every part of the app development process. Find out how to use Qt for app design, development, testing, deployment and publishing.

Make sure to check out Christian’s talk if you’re considering Qt or V-Play as a tool for cross-platform development on a wide range of devices!

You can see a full video of Christian’s presentation from last year here:

Meet Us in San Francisco!

You can meet us at the Summit or in the Bay area and get all of your V-Play questions answered by the development team! Make sure to take advantage of this opportunity to find out the best way to create mobile apps and games in a personal meeting.

You can meet us:

  • At the Qt World Summit on October 19-20
  • Or in the Bay area on Tuesday October 18 and Friday October 21
Make sure to take advantage of this opportunity to find out the best way to create mobile apps and games in a personal meeting.

You can use the button below to get in touch and let us know when you’d like to meet up and have a chat. Make sure to schedule your meeting soon though as we plan on catching up with as many people as possible at the Summit and time slots will soon run out!

Request a Metting in San Francisco!

And even if you’ve met us at events like this before, we’d love to catch up! Just drop us a line and we’ll see you there.

More Posts like This

16 Great Sites Featuring Free Game Graphics for Developers

game graphics

16 Great Websites Featuring Free Game Sounds for Developers

game sounds

The 13 Best Qt, QML & V-Play Tutorials and Resources for Beginners

tutorials capture

21 Tips That Will Improve Your User Acquisition Strategy

User Acquisition

7 Useful Tips That Will Improve Your App Store Optimization

User Acquisition


The post Qt World Summit 2016 – Meet You in San Francisco! appeared first on V-Play Engine.

Customizable vector maps with the Mapbox Qt SDK

by Bruno Abinader, Software Engineer, Mapbox (Qt Blog)

Mapbox is a mapping platform that makes it easy to integrate location into any mobile and online application. We are pleased to showcase the Mapbox Qt SDK as a target platform for our open source vector maps rendering engine. Our Qt SDK is a key component in Mapbox Drive, the first lane guidance map designed for car companies to control the in-car experience. The Qt SDK also brings high quality, OpenGL accelerated and customizable maps to Qt native and QtQuick.

QML: Properties QML: Runtime style
QMLProperties QMLRuntimeStyle

The combination of Qt and Yocto is perfect for bringing our maps to a whole series of embedded devices, ranging from professional NVIDIA and i.MX6 based boards to the popular Raspberry Pi 3.

As part of our Mapbox Qt SDK, we expose Mapbox GL to Qt in two separate APIs:

  • QMapboxGL – implements a C++03x-conformant API that has been tested from Qt 4.7 onwards (Travis CI currently builds it using both Qt 4 and Qt 5).
  • QQuickMapboxGL – implements a Qt Quick (QML) item that can be added to a scene. Because QQuickFramebufferObjecthas been added in Qt version 5.2, we support this API from this version onwards. The QML item interface matches the Qt Map QML type almost entirely, making it easy to exchange from the upstream solution.

QMapboxGL and QQuickMapboxGL solve different problems. The former is backwards-compatible with previous versions of Qt and is easily integrated into pure C++ environments. The latter takes advantage of Qt Quick’s modern user interface technology, and is the perfect tool for adding navigation maps on embedded platforms. So far we have been testing our code on Linux and macOS desktops, as well as on Linux based embedded devices.

Mapbox is on a joint effort with the Qt Company to make the Mapbox Qt SDK also available through the official Qt Location module – we are aligning APIs to make sure Mapbox-specific features like runtime styles are available.

QQuickMapboxGL API matches Qt’s Map QML Type, as you can see from the example below:

import QtPositioning 5.0 
import QtQuick 2.0 
import QtQuick.Controls 1.0 

import QQuickMapboxGL 1.0 

ApplicationWindow {
    width: 640 
    height: 480 
    visible: true

    QQuickMapboxGL {
        anchors.fill: parent

        parameters: [
            MapParameter {
                property var type: "style"
                property var url: "mapbox://styles/mapbox/streets-v9"

        center: QtPositioning.coordinate(60.170448, 24.942046) // Helsinki
        zoomLevel: 14

Mapbox Qt SDK is currently in beta stage. We’re continuously adding new features and improving documentation is one of our immediate goals. Your patches and ideas are always welcome!

We also invite you to join us next month at Qt World Summit 2016 and contribute to Mapbox on GitHub.

The post Customizable vector maps with the Mapbox Qt SDK appeared first on Qt Blog.

Qt Champion nominations for 2016 now open

It is the time of the year, when we can all take a moment to think who has been the most helpful, incredible, kind, skilled and friendly person in the Qt community.

Qt Champions is a way to recognize the individuals who strive to help the community most. They can be found in different places and doing different things, but they are all united in their drive to make Qt a friendly and helpful community.

Past Qt Champions include among others, Samuel Gaist, who has always been helpful and friendly on the forum, and has more posts than anyone else. Iori Ayane, who has written and translated several books into Japanese, and is a key person in the Japanese Qt scene. Robin Burchell, who is a long time Qt contributor doing excellent work in the code base. And Johan Thelin and Jürgen Bocklage-Ryannel, the authors of the QML book.

In addition to the recognition that the Qt Champion title brings, the champions get a full Qt license for a year,  invitations to next years main Qt event and naturally an awesome Qt Champion t-shirt!

So if you have ideas on who should be this years Qt Champion, head over to the Wiki to make your Qt Champion nominations!

The post Qt Champion nominations for 2016 now open appeared first on Qt Blog.

KDAB talks at QtCon 2016



This is a small wrap-up fromQtCon, the biggest Qt event in Europe in 2016, that happened at the beginning of September. At QtCon the Qt community joined forces with the KDE, FSFE and VideoLAN communities, to create an exciting event in the spirit of open collaboration and participation amongst projects.

During QtCon many KDAB engineers gave in-depth technical talks about Qt, QML, Qt3D, OpenGL and the other technologies around Qt development. All the sessions were of the highest quality, as you may expect from KDAB speakers, and extremely well received by the audience.

In case you missed some, here’s a complete list. You can find each talk’s description, slides, code / example material, and a recording of the session by following the links.

In no particular order:

See you at the Qt World Summit!

The post KDAB talks at QtCon 2016 appeared first on KDAB.

Qt on Android: How to create an Android service using Qt

Starting with Qt 5.7, we added the ability to create Android services using Qt.
In this article we’re going to see how to get started and also how to communicate between the two.

Before we get started I want to add a big bold WARNING about the performance! Because the services are run in the background for a very long time, make sure your service doesn’t drain the device battery!

Getting started

Step I: Extend QtService

Every single Qt Android Service must have its own Service java class which extends QtService, so the first step is to create such a service:

// java file goes in android/src/com/kdab/training/MyService.java
package com.kdab.training;
import org.qtproject.qt5.android.bindings.QtService;

public class MyService extends QtService

Step II: Add the service section(s) to your AndroidManifest.xml file

The next step is to add the service section(s) to your AndroidManifest.xml file. To do that you first need to copy & paste the template from https://wiki.qt.io/AndroidServices to your AndroidManifest.xml file, then set android:name attribute with your service class name, as shown in the following snippet:

<application ... >
  <!-- .... -->
  <service android:process=":qt" android:name=".MyService">
  <!-- android:process=":qt" is needed to force the service to run on a separate
                                                        process than the Activity -->

    <!-- .... -->

    <!-- Background running -->
    <meta-data android:name="android.app.background_running" android:value="true"/>
    <!-- Background running -->
  <!-- .... -->

BE AWARE: Every single Qt service/activity MUST run in it’s own process! Therefore for each service you must set a different android:process attribute value.

Step III: How to start the service ?

Now you need to decide how to start the service. There are two ways to do it:

  • on demand
  • at boot time

We’re going to check them both:

Start the service on demand

This is the most common way to start your service(s). To start the service you just need to call Context.startService(Intent intent) method.
The easiest way is to add a static method to your MyService:

// java file goes in android/src/com/kdab/training/MyService.java
package com.kdab.training;

import android.content.Context;
import android.content.Intent;
import org.qtproject.qt5.android.bindings.QtService;

public class MyService extends QtService
    public static void startMyService(Context ctx) {
        ctx.startService(new Intent(ctx, MyService.class));

Then simply call it from Qt to start it:


Start the service at boot time

This method is used quite seldom and is useful ONLY when you really need to run the service at boot time, otherwise I do recommend you to start it on demand.

First you need to add android.permission.RECEIVE_BOOT_COMPLETED permission to your AndroidManifest.xml file:

<application ... >

  <!-- .... -->
  <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />

Then you need to add a receiver element to your AndroidManifest.xml file:

<application ... >
    <!-- .... -->
    <receiver android:name=".MyBroadcastReceiver">
            <action android:name="android.intent.action.BOOT_COMPLETED" />
    <!-- .... -->

And finally, you need to implement MyBroadcastReceiver class, as shown in the following snippet:

public class MyBroadcastReceiver extends BroadcastReceiver {
    public void onReceive(Context context, Intent intent) {
        Intent startServiceIntent = new Intent(context, MyService.class);

Step IV: Where to put your Qt Service code?

Next you need to decide where you’re going to put your service code. Qt (and qmake) has two options for you:

  • in the same .so file with the application
  • in a separate .so file

We’re going to check them both:

Same .so for app & service(s)

Because you’ll have one big .so file, you need a way to know when it will run as an activity or as a service. To do that you just need pass some arguments to your main function. AndroidManifest.xml allows you to easily do that:

<service ... >
    <!-- ... -->
    <!-- Application arguments -->
    <meta-data android:name="android.app.arguments" android:value="-service"/>
    <!-- Application arguments -->
    <!-- ... -->

Then make sure you set the same android.app.lib_name metadata for both service(s) & activity elements:

<service ... >
    <!-- ... -->
    <meta-data android:name="android.app.lib_name"
                android:value="-- %%INSERT_APP_LIB_NAME%% --"/>
    <!-- ... -->

I recommend you to use this method only if your activity and your service(s) share a large piece of code.

Separate .so files for app & service(s)

The second option is to create separate .so files for your app & service(s).
First you need to create a separate server .pro file(s):

TARGET = server
CONFIG += dll
QT += core

The server .so main entry is the main function:

#include <QDebug>

int main(int argc, char *argv[])
    qDebug() << "Hello from service";
    return 0

Last you need to load the server .so file:

<service ... >
    <!-- ... -->
    <meta-data android:name="android.app.lib_name" android:value="server"/>
    <!-- ... -->

Use QtRemoteObject for communication

We’ve seen how to create and how to start a Qt on Android service, now let’s see how to do the communication between them.
There are lots of solutions out there, but for any Qt project, I do recommend you use QtRemoteObject, because it will make your life so easy!

QtRemoteObjects is a playground Qt module led by Ford, for object remoting between processes/devices:

  • exports QObjects remotely (properties, signals & slots)
  • exports QAbstractItemModels remotely
  • creates a replicant on the client side you can interface with
  • repc generates source & replica (server & client) source files from .rep files
    • .rep file is the QtRemoteObjects IDL (interface description language)

As you can see it’s very Qt specific!
Let’s see how to add it to your projects and use it.

Get QtRemoteObjects

QtRemoteObjects project is located at http://code.qt.io/cgit/playground/qtremoteobjects.git/, to get it you need to run the following commands:

$ git clone git://code.qt.io/playground/qtremoteobjects.git
$ cd qtremoteobjects
$ ~/Qt/5.7/android_armv7/bin/qmake -r && make && make install

If needed, replace ~/Qt/5.7/android_armv7 with your Qt version and android ABI of choice.

Use QtRemoteObjects

Using QtRemoteObjects is pretty easy, you need to do a few easy steps:

– add QtRemoteObjects to your .pro files

# ...
QT += remoteobjects
# ...

– create .rep file(s)

class PingPong {
    SLOT(void ping(const QString &msg));
    SIGNAL(pong(const QString &msg));

– add .rep file(s) to the server .pro file

# ...
REPC_SOURCE += pingpong.rep
# ...

– add .rep file(s) to the client .pro file

# ...
REPC_REPLICA += pingpong.rep
# ...

– QtRemoteObjects source(server) side implementation

#include <QCoreApplication>
#include "rep_pingpong_source.h"

class PingPong : public PingPongSource {
public slots:
    // PingPongSource interface
    void ping(const QString &msg) override {
        emit pong(msg + " from server");

int main(int argc, char *argv[])
    QCoreApplication app(argc, argv);

    QRemoteObjectHost srcNode(QUrl(QStringLiteral("local:replica")));
    PingPong pingPongServer;

    return app.exec();

Let’s check the code a little bit.
First you need to implement all .rep interfaces (PingPongSource), then export PingPong object using enableRemoting.

– QtRemoteObjects replica(client) side implementation

#include "rep_pingpong_replica.h"

// ....
    QRemoteObjectNode repNode;
    QSharedPointer<PingPongReplica> rep(repNode.acquire<PingPongReplica>());
    bool res = rep->waitForSource();
    QObject::connect(rep.data(), &PingPongReplica::pong, [](const QString &msg){
        qDebug() << msg;
// ....

Let’s check the code:

  • use QRemoteObjectNode to connect to QRemoteObjectHost
  • use QRemoteObjectNode:acquire to link the local object to the remote one
  • use the acquired object as its local (call slots, connect to signals, etc.)

As you can see, using Qt + QtRemoteObject is (much?) easier and more straight forward than Android’s Java services + AIDL 😉


  • the activities & service(s) must run on a different process.
  • it is not possible (yet) to use QtCreator to easily add a service section to your AndroidManifest.xml file check QTCREATORBUG-16884
  • it is not possible (yet) to use QtCreator to easily generate a service subproject for us, check QTCREATORBUG-16885
  • it is not possible (yet) to see the services logs in QtCreator. You’ll need to use
     $ adb logcat 

    to see it, check QTCREATORBUG-16887

  • it is not possible (yet (hopefully)) to debug the services in QtCreator. This feature will take some time to implement it, therefore I’ll not hold my breath for it, check QTCREATORBUG-16886

Please use the above bug report links to vote for your favorite tasks, the ones that have more votes (usually) are implemented first!

You can find the full source code of this article here: https://github.com/KDAB/android

The post Qt on Android: How to create an Android service using Qt appeared first on KDAB.

RFC: How to fix a tricky leak in QFormLayout?

We have a nasty leak in QFormLayout::setWidget(). In setWidget(), we create the QWidgetItemV2 corresponding to the passed QWidget, and pass that on to Private::setItem, which has a bunch of error returns (guard clauses) that do not delete the item, among them negative row index and cell already occupied.

We could easily fix that missing delete, but this function is also used by setLayout(), say, where the item is the layout.

Conceptually deleting that item (= the nested layout) is completely OK, because the user should be able to rely on the form layout to take ownership of the nested layout, without ifs and buts.

But then we have code in tst_qformlayout that breaks. Simplified, it reads:

   QFormLayout layout;
   QHBoxLayout l4;
   layout.addLayout(-1, QFormLayout::FieldRole, &l4);

I guess you spot the problem? If l4 had been added, everything would’ve been peachy: The QHBoxLayout destructor unregistered itself from layout, which does not attempt to delete l4 when it itself is deleted.

But if l4 is not added for some reason, like in the test code above, the fixed code will attempt to delete l4, which is undefined behaviour, of course (double-delete).

I think such broken code deserves to be broken, for the greater good of fixing a resource leak. Esp. since a double-delete should complain much louder than a leak, and the API user can do something about the double-delete while she can’t do anything about the leak (the pointer is not reachable from outside QFormLayout).

I feel uneasy about adding this to 5.6 LTS, though, so I’ll make a minimal fix there, just for setWidget().

What do you think about the larger fix?

Filed under: English, Qt

Qt Conference Apps – out of the Developer Trenches – Part 1

by Ekkehard Gentz [Independent Software Architect, Consultant] (Qt Blog)

In a few weeks the Qt World Summit 2016 will open its doors in San Francisco and I have been given the chance to speak there about my experiences while developing the Qt World Summit 2016 Conference App. This article series here will give you some additional information to my presentation.

For nearly 40 years I have been developing software, where the last 8 years I have focused on mobile App Development. I started mobile App Development with BlackBerry OS7 (Java) followed by BlackBerry 10 native Apps (Qt 4.8, Cascades UI Controls).

In 2016 BlackBerry, for first time ever, started to build secure Android Phones and my customers asked for x-platform Apps. Personally, I liked the way BlackBerry 10 Apps were built using QML and Cascades. Fortunately Qt just started Qt 5.6 Tech Preview of new Qt Quick Controls 2. I did some first tests to see if Qt Quick Controls 2 will enable me to develop good looking and performant mobile Apps.

First steps went well so I decided to spend some more time and to give Qt 5.7 and Qt Quick Controls 2 a try in real-life projects. Over the last 4 years I built many mobile business Apps for Enterprise and SMB and I also did some Apps for Developer Conferences.

I asked Tero Kojo to develop the QtCon 2016 Conference App as a proof-of-concept to rely on new Qt Quick Controls 2. You can download the QtCon Conference App from Google Play (https://play.google.com/store/apps/details?id=org.ekkescorner.c2g.qtcon), Apple App Store (https://itunes.apple.com/us/app/qtcon-2016-conference-app/id1144162386), Amazon App Store (https://www.amazon.com/ekkescorner-QtCon-2016-Konferenz-App/dp/B01L7DVJTO), as APK (https://app.box.com/s/fgeo14re3hrp47shg915geo1q4gzyxrz) or build it by yourself from Open Source Github Repo (https://github.com/ekke/c2gQtCon_x).

The App was built without any extra native Code – pure Qt only. Feedback was great and I just started to do the Qt World Summit 2016 Conference App – Github Repo will be public soon. Hopefully this time the App will also be available for Windows 10 from Windows App Store. Special thanks to Maurice Kalinowski for his help, the QtCon Conference App is running on Windows 10, although I had some problems uploading this to Windows App Store.

There is a blog series about all my experiences using Qt Quick Controls 2 to develop mobile Apps (http://j.mp/qt-x), also a series in (German) Web & Mobile Developer Magazin and now some articles here at Qt Blog, too. You can expect some 3 – 4 articles here at Qt Blog about developing Qt Conference Apps.

All development is done in my spare time and my goal is to motivate mobile App Developers to try out Qt Quick Controls 2 to develop x-platform Apps. I never did Qt development before, also never did native Apps for Android, iOS or Windows but now I am able to develop and upload Apps to Google Play or Apple App Store :) I am also using Google Material Style to provide a modern mobile App feeling. Thanks to J-P Nurmi, Mitch Curtis and others for great hints HowTo customize Qt Quick Controls 2.

From my experiences over the last 6 months, developing mobile Apps with Qt 5.7 and Qt Quick Controls 2 is much more comfortable and easier than using Xamarin, React Native, Cordova, Angular or Ionic. The good news for all my friends from BlackBerry 10 community: there is a great amount of re-use of C++ Code from Cascades and also architecture style is similar using Signals/Slots and QObject* as data model.

Speed is key to success

The first impression of any mobile App with regards to User Experience comes from starting the App. The User should never have the feeling that an App is slow. Some of my recipes for a speedy start are below:

  • fast creation of C++ Classes
  • immediately show something on the screen
  • be dynamic: only instantiate UI Controls you really need

How am I doing this? Only instantiate C++ Classes, avoid any initialization as open Databases, load Cache Files and more.

DataServer::DataServer(QObject *parent) : QObject(parent)

Use the fastest possible way to show some UI to the User. My root and main Navigation Control is a Drawer. The Drawer contains a list of “Destinations“, where a Destination is a specific area of the Application as

  • Home
  • Schedule
  • Speakers
  • Venue


Each Destination can be one of the Qt Quick Controls 2 Navigation Controls (http://doc.qt.io/qt-5/qtquickcontrols2-navigation.html) or Container Controls(http://doc.qt.io/qt-5/qtquickcontrols2-containers.html):

  • Pane
  • Page
  • StackView
  • SwipeView / Tab Bar

Inside the Drawer you can use a ListView to let the User select a Destination – take a look at Qt Quick Controls 2 Gallery Example. I‘m using a Repeater to create different types of Controls: Destinations, Divider, Header, …

To show the selected Destination best way is to use a StackView as your root UI Control and swap the content – so there‘s always only one Item at this root StackView.


To startup immediately don‘t create all the Drawer – Destinations ! This can easy be done with a little trick: define the Repeater without a data model.

        Repeater {
            id: destinations
            // Don‘t set the model here !
            // model: navigationModel
            Destination {
                id: destinationLoader

So nothing will be created now. To show something to the User create a lightweight Control as initialItem. I‘m using a BusyIndicator.

        // immediately activated and pushed on stack as initialItem
        Loader {
            id: initialPlaceholder
            source: "pages/InitialItemPage.qml"
            active: true
            visible: false
            onLoaded: {
                // Show BUSY INDICATOR
                rootPane.initialItem = item
                // Now something is VISIBLE - do the other time-consuming stuff

The next trick is to start a Timer with a small delay to allow QML to show and animate the BusyIndicator. Then from Timer timeout execute all the initialization stuff and call some Q_INVOKABLE methods from your C++ Classes to load data from Cache and more.

As soon as this is done you can go on with creation of UI Controls. To trigger this set the Repeater Data Model and all the Destinations will be created and HomePage will become current Item on root StackView.

        Timer {
            id: startupDelayedTimer
            interval: 300
            repeat: false
            onTriggered: {
                initialPlaceholder.item.showInfo("Initialize Data ...")
                settings = dataManager.settingsData()
                // … and so on ...
                // inject model into Destinations Repeater
                destinations.model = navigationModel
                // show the Navigation Bars (Drawer and Favorites)
                initDone = true
                // now NavigationBars available
                // show first destination


Here we go: first „real“ Page is visible.

But wait: not all Destinations will really be created from the Repeater – this would take too much time and consume too much memory. All the Destinations are created dynamically using Loaders and I implemented some Activation Policies:

  • Immediate: The Control will be instantiated and remain. I‘m using this only for the first visible Page – the HomePage.
  • When-Selected: First time a User selects a Destination will create the Control and remain. This happens for all Destinations a User normaly will use while the App is running: Schedule, Speakers,…
  • While-Selected: Those Destinations are only created when needed and be destroyed if User changes the Destination. Candidates for this Policy: Help, Settings, About, …

Take a look at the code how all of this is implemented, attend my Session at Qt World Summit 2016 in San Francisco (http://www.qtworldsummit.com/speakers/ekkehard-gentz/) or meet me at #QtWS16.

Stay tuned – next article will cover the QObject* Data Model I‘m using, Caching and Data Binding.

The post Qt Conference Apps – out of the Developer Trenches – Part 1 appeared first on Qt Blog.

Qt Graphics with Multiple Displays on Embedded Linux

Creating devices with multiple screens is not new to Qt. Those using Qt for Embedded in the Qt 4 times may remember configuration steps like this. The story got significantly more complicated with Qt 5’s focus on hardware accelerated rendering, so now it is time to take a look at where we are today with the upcoming Qt 5.8.

Windowing System Options on Embedded

The most common ways to run Qt applications on an embedded board with accelerated graphics (typically EGL + OpenGL ES) are the following:

  • eglfs on top of fbdev or a proprietary compositor API or Kernel Modesetting + the Direct Rendering Manager
  • Wayland: Weston or a compositor implemented with the Qt Wayland Compositor framework + one or more Qt client applications
  • X11: Qt applications here run with the same xcb platform plugin that is used in a typical desktop Linux setup

We are now going to take a look at the status of eglfs because this is the most common option, and because some of the other approaches rely on it as well.

Eglfs Backends and Support Levels

eglfs has a number of backends for various devices and stacks. For each of these the level of support for multiple screens falls into one of the three following categories:

  • [1] Output management is available.
  • [2] Qt applications can choose at launch time which single screen to output to, but apart from this static setting no other configuration option is provided.
  • [3] No output-related configuration is provided.

Note that some of these, in particular [2], may require additional kernel configuration via a video argument or similar. This is out of Qt’s domain.

Now let’s look at the available backends and the level of multi-display support for each:

  • KMS/DRM with GBM buffers (Mesa (e.g. Intel) or modern PowerVR and some other systems) [1]
  • KMS/DRM with EGLDevice/EGLOutput/EGLStream (NVIDIA) [1]
  • Vivante fbdev (NXP i.MX6) [2]
  • Broadcom Dispmanx (Raspberry Pi) [2]
  • Mali fbdev (ODROID and others) [3]
  • (X11 fullscreen window – targeted mainly for testing and development) [3]

Unsurprisingly, it is the backends using the DRM framework that come out best. This is as expected, since there we have a proper connector, encoder and CRTC enumeration API, whereas others have to resort to vendor-specific solutions that are often a lot more limited.

We will now focus on the two DRM-based backends.

Short History of KMS/DRM in Qt

Qt 5.0 – 5.4

Qt 5 featured a kms platform plugin right from the beginning. This was fairly usable, but limited in features and was seen more as a proof of concept. Therefore, with the improvements in eglfs, it became clear that a more unified approach was necessary. Hence the introduction of the eglfs_kms backend for eglfs in Qt 5.5.

Qt 5.5

While originally developed for a PowerVR-based embedded system, the new backend proved immensely useful for all Linux systems running with Mesa, the open-source stack, in particular on Intel hardware. It also featured a plane-based mouse cursor, with basic support for multiple screens added soon afterwards.

Qt 5.6

With the rise of NVIDIA’s somewhat different approach to buffer management – see this presentation for an introduction – an additional backend had to be introduced. This is called eglfs_kms_egldevice and allows running on the automotive-oriented Jetson Pro, DRIVE CX and DRIVE PX systems.

The initial version of the plugin was standalone and independent from the existing DRM code. This led to certain deficiencies, most notably the lack of multi-display support.

Qt 5.7

Fortunately, these problems got addressed pretty soon. Qt 5.7 features proper code sharing between the backends, making most of the multi-display support and its JSON-based configuration system available to the EGLStream-based backend as well.

Meanwhile the GBM-based backend got a number of fixes, in particular related to the hardware mouse cursor and the virtual desktop.

Qt 5.8

The upcoming release features two important improvements: it closes the gaps between the GBM and EGLStream backends and introduces support for advanced configurability. The former covers mainly the handling of the virtual desktop and the default, non-plane-based OpenGL mouse cursor which was unable to “move” between screens in previous releases.

The documentation is already browsable at the doc snapshots page.

Besides the ability to specify the virtual desktop layout, the introduction of the touchDevice property is particularly important when building systems where one or more of the screens is made interactive via a touchscreen. Let’s take a quick look at this.

Touch Input

Let’s say you are creating digital instrument clusters with Qt, with multiple touch-enabled displays involved. Given that the touchscreens report absolute coordinates in their events, how can Qt tell which screen’s virtual geometry the event should be translated to? Well, on its own it cannot.

From Qt 5.8 it will be possible to help out the framework. By setting QT_LOGGING_RULES=qt.qpa.*=true we enable logging which lets us figure out the touchscreen’s device node.  We can then create a little JSON configuration file on the device:

    "device": "drm-nvdc",
    "outputs": [
        "name": "HDMI1",
        "touchDevice": "/dev/input/event5",

This will come handy in any case since configuration of screen resolution, virtual desktop layout, etc. all happens in the same file.

Now, when a Qt application is launched with the QT_QPA_EGLFS_KMS_CONFIG environment variable pointing to our file, Qt will know that the display connected to the first HDMI port has a touchscreen as well that shows up at /dev/input/event5. Hence any touch event from that device will get correctly associated with the screen in question.

Qt on the DRIVE CX

Let’s see something in action. In the following example we will use an NVIDIA DRIVE CX board, with two monitors connected via HDMI and DisplayPort. The software stack is the default Vibrante Linux image, with Qt 5.8 deployed on top. Qt applications run with the eglfs platform plugin and its eglfs_kms_egldevice backend.


Our little test environment looks like this:


This already looks impressive, and not just because we found such good use for the Windows 95, MFC, ActiveX and COM books hanging around in the office from previous decades. The two monitors on the sides are showing a Qt Quick application that apparently picks up both screens automatically and can drive both at the same time. Excellent.

The application we are using is available here. It follows the standard multi-display application model for embedded (eglfs): creating a dedicated QQuickWindow (or QQuickView) on each of the available screens. For an example of this, check the code in the github repository, or take a look at the documentation pages that also have example code snippets.

A closer look reveals our desktop configuration:


The gray MouseArea is used to test mouse and touch input handling. Hooking up a USB touch-enabled display immediately reveals the problems of pre-5.8 Qt versions: touching that area would only deliver events to it when the screen happened to be the first one. In Qt 5.8 this is can now be handled as described above.


It is important to understand the screen geometry concepts in QScreen. When the screens form a virtual desktop (which is the default for eglfs), the interpretation is the following:

  • geometry() – the screen’s position and size in the virtual desktop
  • availableGeometry() – without a windowing system this is the same as geometry()
  • virtualGeometry() – the geometry of the entire virtual desktop to which the screen belongs
  • availableVirtualGeometry() – same as virtualGeometry()
  • virtualSiblings() – the list of all screens belonging to the same virtual desktop


How does the virtual desktop get formed? It may seem fairly random by default. In fact it simply follows the order DRM connectors are reported in. This is often not ideal. Fortunately, it is configurable starting with Qt 5.8. For instance, to ensure that the monitor on the first HDMI port gets a top-left position of (0, 0), we could add something like the following to the configuration file specified in QT_QPA_EGLFS_KMS_CONFIG:

  "device": "drm-nvdc",
  "outputs": [
      "name": "HDMI1",
      "virtualIndex": 0
      "name": "DP1",
      "virtualIndex": 1

If we wanted to create a vertical layout instead of horizontal (think an instrument cluster demo with three or more screens stacked under each other), we could have added:

  "device": "drm-nvdc",
  "virtualDesktopLayout": "vertical",

More complex layouts, for example a T-shaped setup with 4 screens, are also possible via the virtualPos property:

  "outputs": [
    { "name": "HDMI1", "virtualIndex": 0 },
    { "name": "HDMI2", "virtualIndex": 1 },
    { "name": "DP1", "virtualIndex": 2 },
    { "name": "DP2", "virtualPos": "1920, 1080" }

Here the fourth screen’s virtual position is specified explicitly.

In addition to virtualIndex and virtualPos, the other commonly used properties are mode, physicalWidth and physicalHeight. mode sets the desired mode for the screen and is typically a resolution, e.g. “1920×1080”, but can also be set to “off”, “current”, or “preferred” (which is the default).

For example:

  "device": "drm-nvdc",
  "outputs": [
      "name": "HDMI1",
      "mode": "1024x768"
      "name": "DP1",
      "mode": "off"

The physical sizes of the displays become quite important when working with text and components from Qt Quick Controls. This is because these base size calculations on the logical DPI that is in turn based on the physical width and height. In desktop environments queries for these sizes usually work just fine, so no further actions are needed. On embedded however, it has often been necessary to provide the sizes in millimeters via the environment variables QT_QPA_EGLFS_PHYSICAL_WIDTH and QT_QPA_EGLFS_PHYSICAL_HEIGHT. This is not suitable in a multi-display environment, and therefore Qt 5.8 introduces an alternative: the physicalWidth and physicalHeight properties (values are in millimeters) in the JSON configuration file. As witnessed in the second screenshot above, the physical sizes did not get reported correctly in our demo setup. This can be corrected, as it was done for the monitor in the first screenshot, by doing something like:

  "device": "drm-nvdc",
  "outputs": [
      "name": "HDMI1",
      "physicalWidth": 531,
      "physicalHeight": 298

As always, enabling logging can be a tremendous help for troubleshooting. There are a number of logging categories for eglfs, its backends and input, so the easiest is often to enable everything under qt.qpa by doing export QT_LOGGING_RULES=qt.qpa.*=true before starting a Qt application.

What About Wayland?

What about systems using multiple GUI processes and compositing them via a Qt-based Wayland compositor? Given that the compositor application still needs a platform plugin to run with, and that is typically eglfs, everything described above applies to most Wayland-based systems as well.

Once the displays are configured correctly, the compositor can create multiple QQuickWindow instances (QML scenes) targeting each of the connected screens. These can then be assigned to the corresponding WaylandOutput items. Check the multi output example for a simple compositor with multiple outputs.

The rest, meaning how the client applications’ windows are placed, perhaps using the scenes on the different displays as one big virtual scene, moving client “windows” between screens, etc., are all in QtWayland’s domain.

What’s Missing and Future Plans

The QML side of screen management could benefit from some minor improvements: unlike C++, where QScreen, QWindow and QWindow::setScreen() are first class citizens, Qt Quick has currently no simple way to associate a Window with a QScreen, mainly because QScreen instances are only partially exposed to the QML world. While this is not fatal and can be worked around with some C++ code, as usual, the story here will have to be enhanced a bit.

Another missing feature is the ability to connect and disconnect screens at runtime. Currently such hotplugging is not supported by any of the backends. It is worth noting that with embedded systems the urgency is probably a lot lower than with ordinary desktop PCs or laptops, since the need to change screens in such a manner is less common. Nevertheless this is something that is on the roadmap for future releases.

That’s it for now. As we know, more screens are better than one, so why not just let Qt power them all?

The post Qt Graphics with Multiple Displays on Embedded Linux appeared first on Qt Blog.

Your data, your code, your cloud…your choice!

The Internet of Things, can mean, well…so many things. So can platform independence. For many people, a cloud platform, often provided as a service, is an essential part of an IoT offering. For others, flexibility is more important – the flexibility to run your solution on any cloud – or the flexibility to run it internally on your own network on your own servers, because you’re paranoid and believe your competitors are watching you (and you know they are), or even worse, maybe someone is going to try to hack your solution, bring it down and put a serious dent in your up-time track record. Regardless, when developing an IoT solution – the choice should be yours and you should be in charge of your own data.

Qt Top 5 Considerations IoT infographicI was previously involved in the development an IoT strategy for a company operating within the industrial automation space, where we initiated the same IoT project with a third party platform as a service provider (PaaS) – to be part of our offering to our end customers – twice. Yes, twice! Twice, because we were working with the wrong providers and because we came to the same conclusion both times. Twice, because the providers were offering their solution on their cloud and they wanted to rent it to us so we could re-rent it to our end customers.  It didn’t sound right and they would never allow us to move the solution to other cloud platforms or host the solution in any other format. And we could forget about making drastic changes to the back-end system and if we were to make any minor change we had to use their consultants ($$$). In other words, it would have never been our solution – it would have been theirs and they would own the data and eventually most likely reap all the revenue potential once we were locked in. We wanted it to be our solution and our end customers wanted it to be theirs. Flexibility, ownership, cross-platform and cash money being the key words here.

We even tried to pitch the solution to our end customers, but they weren’t buying our story. When we reported the customer feedback to the IoT/PaaS vendor, they replied that our end customers “were being conservative” (no, they weren’t – they were just being smart). They wanted flexibility and control over their own solution and their own data. They valued security. They didn’t want to have some sort of closed software agent sending data from their devices where they couldn’t see what was being sent and to where it was being sent. One of our key customers, who we pitched the solution to, even went to the measure of making us sign a paper stating that no such “IoT software” existed on their equipment and that we would never, ever, EVER connect them to any cloud, which wasn’t their own choice and on which they could not see what data was being sent and where it was being sent to. Period! So we stopped the project. Twice. With the software we created with Qt we didn’t have this problem and you won’t either. With Qt it will be your solution, on your platform of choice and we are not forcing you onto any cloud. It is not that we don’t like the cloud. We do. We just think the choice of how you want to host your IoT solution should be yours and we have developed tools to make that simpler for you. Qt is also open, so you know what is going on and can make sure your data remains yours and you know where it is sent. There is also a bunch of other benefits you can achieve by using Qt in your IoT development. If you want to learn more about the software requirements and other important stuff you should be considering before choosing an IoT platform, read our whitepaper: “Building the Internet of Things and How Qt Can Help”. 

The post Your data, your code, your cloud…your choice! appeared first on Qt Blog.

Internet of Things: Why Tools Matter?

With the Internet of Things (IoT) transformation, it’s obvious that the amount of connected devices in the world is increasing rapidly. Everywhere around our daily lives we all use more and more of them. In addition to being connected, more devices get equipped with a touch screen and a graphical user interface. We have all seen this around us and many Qt users are also deeply involved in creating software for these devices. To bring in some numbers, the Gartner group has estimated that the amount of connected devices will grow to a whopping 20.7 billion by 2020 (and some predict even higher growth, up to 30 billion devices).

Not only is the number of devices growing, but the complexity and amount of software is also increasing rapidly. For example, today’s passenger car can have over 100M lines of code, and this is expected to triple in the future as the functionality of automotive software increases. Cars are on the high side of complexity, but even the simplest connected devices need a lot of software to be able to handle the requirements for connectivity, security and to match the growing usability expectations of consumers.

Here is how the estimated growth of connected devices looks in a line graph:


What is inside these devices? What kind of software drives the connected devices? What kind of skills are needed to build these? It is estimated that 95% of today’s embedded systems are created with C/C++, and that this is not significantly changing in the foreseeable future. Then, on the other hand, according to a study there were 4.4M C++ developers and 1,9M C developers in 2015 in the World. An older study by IDC from 2001, shows that the number of C++ developers was estimated to be 3M back then. This means the number of C++ developers has been growing steadily around 3% per year and is expected to continue with a similar trend – or at least within a similar range.

So, a visualization of C++ developer growth provides the following graph:

The estimated number of devices, most of which will be done with C and C++, is already growing with much faster pace than the amount of C++ developers and the growth is expected to get even higher. Due to the increased complexity of functionality, the amount of software needed in the devices is also growing. Although some of the new devices will be very simple in functionality, on average the devices get more and more complex to meet consumers’ requirements.

Now, comparing these two trends together gives us an interesting paradox: How can the few millions of C++ developers match the requirement to build the dozens of billions of connected devices in the future?

Putting these two graphs together, we can clearly visualize the paradox (and a possible solution):



So how does this add up? Do we expect a 2020 C++ developer to write 20 times more code than a decade ago? That does not work. Even if all the C++ developers would focus into embedded, with no one creating and maintaining software for desktop and mobile applications, there still may not be enough developers. C++ developers can’t be easily trained from other professionals – programming is a skill that takes years to learn and not everyone can master.

So, Something needs to be done to facilitate two things: Enabling the C++ developers to be more productive and also helping the non-C++ developers to create the devices.

Therefore, the approach for creating embedded software needs to be adapted to the new situation. The only way to cope with the growth is to have good tools for embedded device creation and to increase the reuse of software. It is no longer viable to re-invent the wheel for each product – the scarce programming resources have to be targeted into differentiating functionality. Organizations will have to prioritize and focus into where they add value the most – anything that can be reused should not be created inhouse. Using tools and frameworks like Qt is the only viable approach to create the envisioned devices. The old Qt tagline: “Code less. Create more. Deploy Everywhere” is more relevant today than it has ever been. Qt has a solid track record from embedded, desktop and mobile development, making the creation of applications easy in any platform and also across multiple platforms.

It is likely that even reuse of software assets is not enough. It is also necessary to increase productivity of the C++ developers and to extend the personnel creating the software beyond the ones who master C++. Using the widely renowned and well-documented Qt API functionality and excellent development tools, C++ developers are more productive than before. Qt also provides an easy-to-use declarative QML language and visual design tools for user interface creation, growing the amount of people who can create software for embedded beyond the C++ developers. There are already over million developers familiar with Qt, and new developers across the world are taking it into use every day.

With the QML language, visual UI design tools and functionality for embedded devices does not mandate C++ skills for every developer in the team. It will still be necessary to have core C/C++ developers when making embedded devices, but others can help as well. Using Qt allows both non-C++ developers to create some of the needed functionality and the C++ developers to be more productive.

To increase developer productivity and to extend the developer base, Qt offers otherwise unseen ease of embedded development. Qt provides many of the common development boards supported out of the box, one click deployment to target device, built-in device emulator, on target debugger, performance analyzer, visual UI designer and many more tools in the integrated development environment. With the integrated tools and extensive API functionality, developing with Qt is unlike traditional embedded development. Qt makes embedded development almost as easy as creation of desktop or mobile applications.

The future is written with Qt.

To learn more about the latest developments of Qt, join us at the Qt World Summit October 18-20th 2016 in San Francisco, USA.

We’re also hosting an online panel discussion with industry experts around IoT and software in general September 27th. Register today for the webinar for an interesting fireside chat!

The post Internet of Things: Why Tools Matter? appeared first on Qt Blog.

Qt World Summit 2016 San Francisco Conference App: Behind The Scenes

Qt World Summit 2016

Meet me at this years Qt World Summit 2016 in San Francisco


I’ll speak about development of upcoming Qt World Summit Conference App running on

  • BlackBerry 10 (Qt 4.8, Cascades)
  • Qt 5.7 (Qt Quick Controls 2)
    • Android
    • iOS
    • Windows 10

My Session

See how easy it is to develop cross-platform mobile Apps using Qt 5.7+ and new Qt QuickControls 2


BlackBerry 10 Cascades Development ?

Already have BlackBerry 10 Apps (Cascades) ? Learn how to save your investment: most C++ Code für Business Logic, REST / Web Services, Persistence (SQLite, JSON) can be re-used and the app architecture is similar using Qt SIGNALS – SLOTS concept.

cu in San Francisco

Filed under: BB10, C++, Cascades, mobile, Qt

QtCon wrap up


First, a huge Thank You to everyone who was at QtCon!

We had an incredible time in Berlin. First the training day by KDAB and then three conference days packed full with topics ranging from how to set up an open source organisation to fine tuning Qt graphics.

Second. a shout out to the communities that we had the pleasure to work with to create QtCon, FSFE, KDE and VideoLAN, and of course to our partners KDAB, you guys rock!

Last but definitely not least, Thank You obviously to all the volunteers from the different communities!

The magic of QtCon

When we originally got together to plan QtCon, we envisioned it as a meeting of communities, one event where everyone can come. This is something we achieved. At the end of the event, every one of the community representatives made the same comment; meeting new and interesting people was the best part. Chatting about new things over coffee or lunch, walking from a deep dive technical session to the social impact of open source was something that only happens when we have different communities mix. By the end of the event, I believe everyone headed for home with a feeling that getting together is something we need to do more often.

The Keynotes were amazing! Please take the time to hear what Raul, Leslie and Julia had to say in their talks. The take-home message for me was that software has changed the world and we need to understand the change on every level. For Qt this means that we need to be sensitive to these changes and understand the impact we have in society.

The Qt Specific topics covered everything happening in and around Qt – from the technical details to overall community issues.

The most awaited Qt session was naturally the talk on the status and future of Qt by Chief Maintainer Lars Knoll. The talk outlined the bigger trends in Qt, and where biggest development pushes are expected to be. Lars also talked about how he sees the next releases of Qt going forward. These topics continued in corridor discussions and during the evening party on Friday.IMG_20160902_161511

My personal favourite talk was an ‘unconference session’ that was reserved on location about Qt QUIPs, a way to arrange and manage the information related to the Qt project. I’m looking forward to seeing QUIPs in action, but it will naturally take a while for the developers to get all the bits and pieces together.

The Qt session videos will be available soon on the QtStudios YouTube channel. However if you are really hungry to get at the videos, in the QtCon schedule the talks that were in the bigger rooms already have the links added to the talk descriptions. For example The Qt Project Status talk video is here. The incredible speed at which the videos got online is entirely due to the hard and efficient work of the CCC Video Operations Center, hats off to them!

In conclusion, I met old friend, new and interesting people, heard cool talks and had a good time. I’m sure the other attendees did too.

See you in coming events!

P.S. Qt World Summit is coming up soon 😉

The post QtCon wrap up appeared first on Qt Blog.

Squish tip of the week: Automating Multiple Applications with Multiple Squish Installations or Editions

Automating Multiple Applications with Multiple Squish Installations or Editions

Did you know that it is possible to use multiple Squish editions in a single test script?

The following example describes the setup and workflow for such scenario utilizing Squish for Qt and Squish for Web.

  1. Install Squish for Qt.
  2. Install Squish for Web.
  3. Create a Squish for Qt test suite with the Squish for Qt IDE.
  4. Create a Squish for Web test suite with the Squish for Web IDE.

  5. Share the objects.map file across both test suites (Learn how to share an Object Map).
  6. Decide which of the two test suites should be the main test suite. In our example, we choose the Squish for Qt test suite.
  7. Continue with Recording
  8. Continue with Replay

Note: The information above describes the setup for Squish for Qt and Squish for Web but the instructions are not limited to these Squish editions.

Related topics

Creating Certified Medical Devices with Qt

by Matthias Hölzer-Klüpfel [Medical Devices Consultant] (Qt Blog)

Many modern medical devices provide a graphical interface to the user. In dialysis machines, for example, touch screen interfaces to set up the treatment parameters and to monitor the treatment progress are commonplace. Qt is a viable technical solution to implement those interfaces, so it is used in quite a number of medical devices.

When designing and implementing a medical device, however, you have to do more than to find a good technical solution. You have to analyze the risks associated with your device, and you have to make sure that your system design and development is appropriate for that risk. That is not an easy task, but there are laws, regulations and standards that provide guidance on the required development process for medical device software. Important guidance documents are:

If you develop software for a medical device that will be marketed in the EU and the US, you will have to follow those guidelines. They are mainly concerned with the process of designing, implementing, verifying and testing your own device software. But they also influence the use of third-party software like Qt in your device. If your third-party software, or SOUP (“Software of Unknown Provenance” in terms of IEC 62304), may contribute to a hazardous situation, i.e. might lead to harm to the patient, you have to minimize that contribution and make sure that the chosen third-party software is appropriate.

If we continue the example of a dialysis machine, one of the functions of the therapy – besides cleaning the blood of the patient – is to remove excess water from the body of the patient. Depending on the physical condition of the patient, up to four liters of water may be removed in a typical therapy session. But that is just the maximum amount, a patient might need less water removal, or none at all. The problem is that you have to enter the right amount of water to remove via the user interface, and it is critical that you do not remove more than that amount, as removing too much water might lead to a circulatory collapse and might severely harm the patient. Input of safety-critical values is a typical critical user interface function in medical devices, as well as the output of safety-critical values, e.g. the oxygen saturation of a patient’s blood.

Another critical user interface function that is common in medical devices is alarms. Imagine that during a dialysis therapy, the device detects that there is an air bubble in the blood line (which, when infused back into the patient, might lead to embolism). What the device probably should do is to stop the therapy, sound an alarm sound and display a visual warning to the operator of the device to take appropriate actions.

Obviously, if one of those functions fail to work correctly, the patient may be harmed. Now a manufacturer might ask some basic questions:

  • 1. What can we do to prevent the harm to the patient?
  • 2. May we use Qt to implement those safety-critical user interface functions?
  • 3. Do we need a validated toolkit to build a safety-critical user interface?

Let’s start with the first question. It can only be answered by performing a detailed risk analysis. The standard ISO 14971 provides guidance on how to do this. In the example of the air-in-line alarm, we start with the hazard (the air bubble), determine the potential harm (which – in the worst case – is the death of the patient) and try to estimate the probability of the harm (for the sake of the example, let’s assume an air bubble once per 24 hours of treatment). If we combine those assumptions and estimates, we will find that the risk (the combination of the severity of the harm and the probability of its occurrence) is not acceptable. Thus we need to do something to reduce the risk. We might decide to add an air-bubble-detector into the system, and to add an alarm function to the user interface. When a bubble is detected, the system stops the therapy and raises the alarm to request the user to take appropriate action.

This is a reasonable first step, but not the end of our analysis. What happens if the alarm is not displayed? This could be caused by a problem with the display driver, or a failing LCD backlight, or by an unexpected failure of the GUI toolkit. A medical device needs to be safe even in the presence of a single fault in the system. So having an alarm system that might fail because of a single reason is not acceptable. Typical devices would therefore add another redundant and diverse alarm mechanism, e.g. a flashing LED that can be activated even when the GUI is not working properly. With this second channel, the alarm can be indicated even with a failure in the GUI or a failure in the LED mechanism. And this is generally considered to be safe. Of course, there is a cost – additional hardware.

There are other examples of diversity in graphical user interfaces: If we display a critical numerical value, we might be concerned that loading the correct font fails. Remember, we have to assume a first fault like a damaged font file. We can add some redundancy and display a bar graph visualizing the numerical value in addition to the number. Even if the numbers are not displayed correctly, the bar graph will present the information to the user. Sometimes you will see an old-fashioned LCD screen next to a touch screen on a medical device. This is a secure (if not pretty) way to add redundancy to the display system. The important point is that the resulting risk, even with a failure in the GUI, has to be acceptable.

Now we can tackle the second question: May we use Qt for the GUI of a safety critical medical device? Principally, the choice of technologies is up to the system designer. None of the standards will tell you to choose one toolkit over the other. The manufacturer of the medical device needs to make sure that it is safe, according to what has already been mentioned. But in addition to that, the IEC 62304 and the OTS require that we make a conscious decision about the choice third-party software or SOUP. In addition to the mentioned risk analysis, we need to make sure that:

  • The toolkit provides the functionality and performance that we depend on
  • The device provides the support necessary to operate the toolkit within its specification
  • The toolkit performs as required for our system

So a device manufacturer will have to provide evidence of these claims, i.e. will have to document the requirements to Qt, analyze and document the requirements imposed by Qt on the system and you will have to perform some degree of testing in the system to prove the requirements are met. And the manufacturer needs to set up a monitoring process to regularly check the bug list of the third-party software component and to assess if any new bugs impose additional risks to the patients. All of these points might be subject to an audit by a notified body or the FDA.

Very often the following question will be asked: Where can we buy a GUI toolkit that has already been validated to be suitable for use in safety-critical medical devices? Unfortunately, there is no such thing as a pre-validation for medical devices. As the starting point of third-party component validation is focused on the risk analysis, only the manufacturer of the device can do the qualification, because only the manufacturer can identify the risks. Therefore, IEC 62304 and the FDA regulations do not define a certification process for third-party software (SOUP). The best way a vendor can support a medical device manufacturer therefore is by providing good documentation of its development process and proof of internal testing, which allows the manufacturer to asses if it is appropriate for the planned application.

If you use a commercial license of Qt, contact The Qt Company and request a description of the QA practices and test report of the Qt version you intent to use. These documents are readily available and support your qualification effort.

To summarize, if you plan to use Qt for safety-critical functions in a medical device, make sure to:

  • 1. Identify all risks that might be caused by failures of the user interface
  • 2. Try to mitigate those risks by means outside the user interface, e.g. by redundant inputs and outputs
  • 3. Build redundancy into the user-interface itself to protect against single-fault failures
  • 4. Carefully select the software components you use to implement the user interface
  • 5. Document the rationale for your decision that Qt is appropriate for your device so it can be reviewed by external auditors

If you follow those steps, you will be able to design your device with a modern user interface, and still meet all the safety requirements.

About the Blog Post Author:

Matthias Hölzer-Klüpfel is an independent consultant, trainer and contractor concerned with development processes and project management for medical device software. He co-founded the association “International Certified Professional for Medical Software Board e.V.” which provides the foundation for a certified education program for medical device software development.

You can reach Matthias via matthias@hoelzer-kluepfel.de if you have any further questions.

Earlier Blog Posts about Functional Safety with Qt:

If you are interested in hearing more about Functional Safety, there is a talk at Qt World Summit by Tuukka Turunen about ‘Creating Functional Safety Certified Systems with Qt’.

The post Creating Certified Medical Devices with Qt appeared first on Qt Blog.

Qt 5.8 Alpha released

I’m happy to let you know that we have now reached our first milestone towards the release of Qt 5.8. The Alpha version of Qt 5.8 is now ready, and can be downloaded from download.qt.io or your Qt Account. As a new minor release, Qt 5.8 comes with a lot of new features as well as many bug fixes and improvements. We’ll go through all the new features in more detail as we get closer to the release. For now, let me just mention some of the biggest changes.

New graphics architecture

With Qt 5.8, the graphics architecture for Qt Quick has undergone a larger rewrite. The goal was to remove the tight dependency of Qt Quick onto OpenGL that we have had since Qt 5.0, and make the architecture more agnostic with regards to the graphics API that is being used. The new infrastructure has been used to create a vastly improved Software rendering backend for Qt Quick, and a backend based on DirectX 12.

QML caching

The QML engine has also seen some major improvements with a new caching infrastructure, that can cache the QML files in a precompiled binary form. This infrastructure does help to significantly speed up loading of QML applications once the binary cache has been created. It also helps reduce memory consumption. Ahead of time compilation of Qt Quick continues to be supported through the commercial Qt Quick Compiler.

Qt Lite Project and configurability

Even though Qt is split up into many modules, it is a large framework with many features. Many of our customers are using only parts of them, and have been asking for an option to create tailored builds of Qt for their use case. This is especially important for embedded devices, where both RAM and Flash storage are often limited.

To accommodate this, we have over the last 6 months done significant work on our build infrastructure to give our users much more fine grained control over the way how Qt is being built. This is what we called the Qt Lite Project. The basic infrastructure for this is now in place with the 5.8 Alpha, but we will be doing some more work on it while moving towards the Beta release.

With Qt 5.8, we will add a new tool to Qt for Device Creation, that will make it easier to tailor your Qt build and remove all the pieces of functionality that you are not using in your embedded project. From initial measurements, we expect that you will be able to reduce the size of a statically linked Qt Quick application by up to 70% compared to Qt 5.6.

New modules

The Wayland Compositor, SCXML and Serial Bus modules have now graduated from Technology Preview to being fully supported. In addition, we added Qt Speech and Qt Network Authentication (featuring OAuth support) as new Technology Previews.


With the Qt 5.8 Alpha being released, we are now focusing fully towards finalizing a couple of remaining items, and plan to have the beta ready for you towards the beginning of October and Qt 5.8.0 final by end of November.

If you would like to hear more about all the cool new things coming with Qt 5.8, we will have in-depth talks about all of them at the Qt World Summit in San Francisco.

I hope you’ll enjoy the Qt 5.8 Alpha. Please download it from download.qt.io or your Qt Account, and don’t forget to give us feedback by writing to the mailing lists or reporting bugs.

The post Qt 5.8 Alpha released appeared first on Qt Blog.

In 45 Minutes: from Scratch to App for Android, iOS, Windows 10

As you know last months I evaluated Qt 5.7 and new Qt Quick Controls 2 for x-platform mobile App development.

Qt Con Conference App

You can see a first App live at Google Play, Apple App Store or Amazon App Store: Search for ‘QtCon’:


The Application is available Open Source at Github.

Blog with some more details: here.

Next Conference App for Qt World Summit in San Francisco will also be available from Windows App Store (Windows 10) and BlackBerry World (BlackBerry 10)

Talk at Code Talks in Hamburg

I will demonstrate the power of Qt 5.7 / Qt Quick Controls at Code Talks in Hamburg:

in 45 Minutes from Scratch to App


BlackBerry 10

Perhaps you’re asking “And what about your BlackBerry 10 Development, ekke ?

Nothing has changed – I’m still developing business Apps for BlackBerry 10 – and the good thing: I can re-use most of the C++ / Qt Code for Android / iOS / W10🙂 Also App Architecture and events (Qt SIGNALS – SLOTS concept) are similar.

Filed under: BB10, C++, Cascades, mobile, Qt