KDAB Training at Qt World Summit Berlin

KDAB is offering eight superb Training Classes in Berlin, you can see the list below, which includes one run by our long-term collaborator, froglogic. All the rest are delivered by KDAB engineers.

There are five classes in our Introductory group, and three in the Advanced. Read the descriptions carefully to see which one you’d like to attend. An Introductory class can be just what you need for a refresher, even if you’re an experienced programmer, as our trainers are always up-to-date with the latest tips.

Effective 3D in Qt
Introduction to CMake
Introduction to Qt/QML
Multithreading in Qt
Qt GUI Testing with Squish

Modern C++ – What’s New in C++17?
Profiling and Debugging for Linux
QML Applications Architecture



Effective 3D in Qt

with James Turner

Target Audience: Qt developers wishing to integrate 3d technology in their application.

Prerequisites: The audience is expected to have familiarity with basic QtQuick and OpenGL concepts, but no in-depth knowledge of them is required.

Course Description

Starting with the utility and enabler classes (for OpenGL, Vulkan and the upcoming Metal support), we will look at low level support for using OpenGL with QOpenGLWindow for rendering and event handling. We will also look at the support in the Widgets module.

Later we will show the technologies available in Qt that allow deep integration of Qt Quick 2 scenes with custom drawn OpenGL content. We will discuss the possibility of simply providing a Qt Quick overlay for an OpenGL scene. The discussion will then proceed to the creation of custom Qt Quick Items drawn using raw OpenGL commands, which can then be used from QML. We will also illustrate how to manually drive Qt Quick’s own rendering if we need to be in complete control of how and when the rendering happens.

Finally, we will look at Qt 3D and how to use its scene graphs and frame graphs to create high performance 3d rendering without requiring the specialist knowledge required when accessing OpenGL directly. Along the way we will introduce the Qt 3D renderer and input systems and how they are built on top of a flexible, highly threaded, Entity Component System (ECS) architecture that scales very well and is ripe for future additions.

You will learn how to:

  • create windows for 3d rendering
  • add a Qt Quick based UI to an OpenGL application
  • create custom high performance Qt Quick Items using OpenGL
  • integrate your own OpenGL renderer with the Qt Quick Renderer
  • construct a basic Qt 3D application
  • make a scene graph, display 3D graphical content using geometry, materials, textures
  • get Qt 3D maps onto the graphics pipeline
  • extend Qt 3D to use your own custom geometry
  • write custom materials and shaders
  • completely control the Qt 3D renderer dynamically at runtime using the Frame Graph
James Turner

Senior Software Engineer and team lead at KDAB, James has been developing with Qt since 2002. He contributes to the current maintenance of Mac platform support as well as the development of OpenGL and 3D support in Qt. James has a background in user-interface, graphics and simulation development as well as a long history of development on OS-X and prior versions of Mac OS. He is a lead developer on FlightGear, the open-source flight simulator, and holds a BSc in Computer Science.

Introduction to CMake

with Kevin Funk

Target Audience: C and C++ Developers who are interested in how to build their code.

Prerequisite: Experience with build systems.

“The best thing a build system can do is not get in the way”.

Course Description

CMake is the de facto standard build system for C and C++ outside of frameworks that require their own. It has earned this place by supporting the situations and special cases that arise in real projects.

Support for CMake within Qt is being significantly improved and there are longer term plans to switch to CMake for building Qt itself. It’s currently a good alter- native if you hit limitations in qmake.

This course will teach the basics of creating and building projects with CMake.  In recent years, CMake has introduced some cleaner and more precise constructs. The course will focus on the new constructs where possible.

Why learn CMake? CMake has broad functionality that covers many real world problems. Learning CMake enables you to solve advanced build requirements. This includes cross-platform builds, feature detection based on platform or available libraries, built- time configurable feature switches and custom build steps. CMake is increasingly widely adopted across the industry.

Kevin Funk

Kevin has actively developed with Qt/C++ since 2006 and has a special interest in tooling and profiling. He’s an active contributor to KDAB’s GammaRay analyzer (a high-level Qt application debugger) and has a strong emphasis on state machine tooling. He is co-maintainer of the KDevelop IDE, a powerful C/C++ development environment backed by Clang, and is pushing for cross-platform success inside KDE. Kevin holds a Masters Degree in Computer Science.

Introduction to Qt/QML

with Jan Marker

Target Audience: Developers and managers interested in learning the autonomy of a QML application.

Prerequisite: Knowing the basics of Qt at C++ level is an advantage but not a requirement.

Course Description

This training is an introduction to Qt Quick. On the one hand it will teach you how to compose fluid user interfaces with slick animations using the QML language. On the other hand it will teach you how you hook the QML side up to your business logic in C++.

Course contents

  • Connecting a QML UX with C++ business logic
  • Complex list views including data provided from C++ models
  • Custom objects implemented using Qt Quick scene graph
  • Profiling and best practices for optimal performance

Why learn Qt/QML? Designed to take people new to Qt or QML, from the basics to a deep functional understanding of best practices, this Qt/QML training will equip you with the skills and know-how to boost your productivity at work.

Jan Marker

Software Engineer at KDAB, Jan has been using Qt since 2009 when he started contributing to the KDE project. Since joining KDAB he has worked on multiple large Qt and QML projects, while more recently also developing Wayland compositors. Besides in-depth knowledge of Qt and C++, Jan also has a deep interest in other technologies like NodeJS. He holds a BSc in Computer Science.

Multithreading in Qt

with Kevin Krammer

Target Audience: Qt Developers interested in multithreaded programming.

Prerequisite: Knowledge and experience programming with Qt and C++. A basic understanding of multithreaded programming is an advantage but not required.

Course Description

Multithreaded programming is essential for developers to create fast and responsive applications on computers, phones, and embedded devices all with an increasing number of cores. Qt offers several mechanisms for multithreading; however, it can be difficult to know which to use and how to steer clear of common pitfalls. This course offers guidance how to write safe and efficient multithreaded code with Qt.

Topics include:

  • Basic multithreading concepts (threads, processes, data races, reentrency, shared data)
  • Synchronization primitives (mutexes, semaphores, condition variables)
  • Special concerns for Qt applications (cross-thread signals/slots, QObject thread affinity, the GUI thread)
  • Low-level multithreading with Qt (QThread, QThreadPool, QMutex, etc)
  • High-level multithreading with Qt (QtConcurrent)
  • Threading with Qt Model/View
  • A brief summary of atomic operations

Why learn about Multithreading with Qt? Multithreaded development is a complex subject where it is easy to write code that contains severe bugs yet looks correct. This training will provide a solid foundation for writing safe and effective multithreaded code in Qt applications.

Kevin Krammer

Senior Software Engineer and team lead at KDAB, Kevin has actively developed with Qt and contributed consistently to KDE since 2000. He is a founding member of the QtCentre website and has mentored at Google’s Summer of Code program for 10 years. One of KDAB’s most experienced trainers, Kevin keeps our training material up-to-date and has trained engineers from Blackberry, Lockheed Martin, Siemens and Safegate and many others. Kevin holds a BSc in Software and Communications Engineering.

Qt GUI Testing with Squish

with Tomasz Pawlowski

Prerequisites: The course is for developers and testers already familiar with the basic concepts of Qt.

Course Description

In order to achieve high quality applications during testing process all the functionality of the software shall be covered, including fully exercising GUI itself. For regression testing automating this process gives benefits, saving execution time and increasing accuracy. On the other hand, GUI Automation might be a challenge, as GUI may change significantly during a product life cycle.

In this course we learn how to design and implement cross-platform automated tests using Squish GUI Tester for Qt, QML & QtQuick applications that continue to work as your product evolves.

  • Introduction to GUI Testing
  • Squish Overview (installation, configuration)
  • Test Script Creation and Execution
    • Recording and Replaying Test Scripts
    • Verification Points (Properties, Screenshot, Visual)
    • Test Results and Logging
    • Squish API
    • Image-Based Lookup
  • Development of Test Cases at Business Level
  • Set-Up and Tear-Down Functions
  • Debugging Test Scripts
  • Object Recognition
  • Accessing Application Internals (Inspecting, Object Properties and Methods)
  • Synchronisation and Event Handling
  • Squish Command-Line Tools
  • Working with Multiple Applications
  • Hooking into Running Applications
  • Squish Integration with CI
Tomasz Pawlowski

Software engineer at froglogic, Tomasz started the adventure with Squish and GUI Testing in 2011, designing and implementing automated tests for a Flight Planning solution at Lufthansa Systems. In 2014 he joined froglogic and is conducting Squish trainings and consulting for many companies in Europe, India and the USA. Additionally, Tomasz is implementing Squish integrations. Tomasz has a degree in computer science from Nicolaus Copernicus University in Poland.


Modern C++ – What’s New in C++17?

with Giuseppe D’Angelo

Target Audience: C++ developers who want to know more about the new features introduced in C++17.

Prerequisite: Knowing the basics of C++11 is a requirement, though more advanced topics will be explained as needed.

Course Description

Starting with C++11 released in 2011, the C++ language and standard library have steadily evolved. At the end of 2017 the new C++17 standard was released, adding a sizable amount of useful new features. All major compilers already support most (if not all) of its features.

In this training, the most useful of the new features introduced in C++17 and its predecessor will be presented. In cases for which these features depend on features introduced in C++11 or C++14, these will be refreshed as well.

New library features being presented include the new types std::any, std::optional and std::variant, the new parallel algorithms, filesystem access, std::string_view and new operations on the container classes. The new language features range from ways to improve template code with fold expressions, constexpr if, and class template deduction over improvements of lambdas to structured bindings and initalizers in if and switch statements.

Why learn what’s new in C++17? C++ is the language that powers most applications written with Qt. To make the most out of the language, developers need to know its capabilities and pitfalls, and keep up with the incremental changes done in new releases. Doing so rewards them with ways to write easier, faster, cleaner and safer code

Giuseppe D’Angelo

Senior Software Engineer at KDAB, Giuseppe is a long-time contributor to Qt, having used Qt and C++ since 2000, and is an Approver in the Qt Project. His contributions in Qt range from containers and regular expressions to GUI, Widgets and OpenGL. A free software passionate and UNIX specialist, before joining KDAB, he organized conferences on opensource around Italy. He holds a BSc in Computer Science.

Profiling and Debugging for Linux

with Milian Wolff

Target audience: Developers who want to find and fix problems,

Prerequisite: Knowing the basics of C++ and Qt,

Course Description

This training introduces various tools, which help developers and testers in finding bugs and performance issues. This variant of the training focuses on Linux.

The tools presented cover a wide range of problems, from general purpose debugging and CPU profiling to Qt specific high-level analyzers. Often, it is relatively simple to run a tool, but interpreting the results, or even just using some of the more advanced tools, requires deep technical knowledge. The following tools will be covered:


  • General purpose debugger: GDB
  • Record and replay, reverse debugging: RR
  • Memory error detectors: AddressSanitizer
  • Thread error detectors: ThreadSanitizer
  • Various Qt built-in features
  • GammaRay to investigate internals of Qt Applications

Static Code Analysis

  • Compilers
  • Clazy


  • CPU: Linux perf and hotspot
  • Heap memory: heaptrack
Milian Wolff

Senior Software Engineer at KDAB, Milian leads the R&D in tooling and profiling in which he has a special interest. Milian created Massif-Visualizer and heaptrack, both of which are now used regularly to improve the performance of C++ and Qt applications. When not applying his knowledge to improving code-base performance for KDAB’s customers, Milian maintains QtWebChannel for the Qt Project and is co-maintainer of the KDevelop IDE. In 2015, Milian won KDE’s Akademy Award for his work on Clang integration. He has a Masters Degree in Physics.

QML Applications Architecture

with Tobias Koenig

Target audience: QML developers who want to learn about creating large-scale yet maintainable applications.

Prerequisite: Being comfortable with the basics of QML, as well as some familiarity with developing with C++ and Qt (QObject, signals & slots, properties, etc).

Course Description

QML is a great language for expressing user interfaces in a declarative, easy to understand way. It can however be difficult to scale up from small demo applications to fully featured, complex systems without paying too high a price in complexity, performance and maintainability. In this course, we explore different techniques to deal with these issues to enable you to scale up your applications while steering clear from the common pitfalls.

Topics include:

  • Custom QML items
  • C++ integration
  • Declarative coding
  • Multi-page application architectures
  • Code organization
Tobias Koenig

Senior Software Engineer at KDAB, Tobias has actively developed with Qt since 2001 and has been an active KDE contributor during this time. His contributions have been mainly to the KDE PIM project and the KDE libraries, but also to other open source projects.

There’s still seats left for the One-Day Training at Qt World Summit in Berlin!

Sign up…

The post KDAB Training at Qt World Summit Berlin appeared first on KDAB.

Composing AST Matchers in clang-tidy

When creating clang-tidy checks, it is common to extract parts of AST Matcher expressions to local variables. I expanded on this in a previous blog.

auto nonAwesomeFunction = functionDecl(

  , this);

  , this);

Use of such variables establishes an emergent extension API for re-use in the checks, or in multiple checks you create which share matcher requirements.

When attempting to match items inside a ForStmt for example, we might encounter the difference in the AST depending on whether braces are used or not.

#include <vector>

void foo()
    std::vector<int> vec;
    int c = 0;
    for (int i = 0; i < 100; ++i)

    for (int i = 0; i < 100; ++i) {

In this case, we wish to match the push_back method inside a ForStmt body. The body item might be a CompoundStmt or the CallExpr we wish to match. We can match both cases with the anyOf matcher.

auto pushbackcall = callExpr(callee(functionDecl(hasName("push_back"))));

    , this);

Having to list the pushbackcall twice in the matcher is suboptimal. We ca do better by defining a new API function which we can use in AST Matcher expressions:

auto hasIgnoringBraces = [](auto const& Matcher)
    return anyOf(

With this in hand, we can simplify the original expression:

auto pushbackcall = callExpr(callee(functionDecl(hasName("push_back"))));

    , this);

This pattern of defining AST Matcher API using a lambda function finds use in other contexts. For example, sometimes we want to find and bind to an AST node if it is present, ignoring its absense if is not present.

For example, consider wishing to match struct declarations and match a copy constructor if present:

struct A

struct B
    B(B const&);

We can match the AST with the anyOf() and anything() matchers.

    , this);

This can be generalized into an optional() matcher:

auto optional = [](auto const& Matcher)
    return anyOf(

The anything() matcher matches, well, anything. It can also match nothing because of the fact that a matcher written inside another matcher matches itself.

That is, matchers such as


match ‘trivially’.

If a functionDecl() in fact binds to a method, then the derived type can be used in the matcher:


The optional matcher can be used as expected:

    , this);

Yet another problem writers of clang-tidy checks will find is that AST nodes CallExpr and CXXConstructExpr do not share a common base representing the ability to take expressions as arguments. This means that separate matchers are required for calls and constructions.

Again, we can solve this problem generically by creating a composition function:

auto callOrConstruct = [](auto const& Matcher)
    return expr(anyOf(

which reads as ‘an Expression which is any of a call expression or a construct expression’.

It can be used in place of either in matcher expressions:

        hasArgument(0, integerLiteral().bind("port_literal"))
    , this);

Creating composition functions like this is a very convenient way to simplify and create maintainable matchers in your clang-tidy checks. A recently published RFC on the topic of making clang-tidy checks easier to write proposes some other conveniences which can be implemented in this manner.

Getting Started With Qt for WebAssembly

by Morten Johan Sørvig (Qt Blog)

We’ve previously blogged about some of the features of Qt for WebAssembly. In this blog post we’ll take a look at how to get started: building Qt, building your application, and finally deploying the application.

If you would like to know more about this topic, then please join me for the Qt for WebAssembly webinar on November 27th.


The first step is installing emscripten. Please refer to the emscripten documentation for how to do so, and also note that Qt requires a unix host system: GNU/linux, macOS, or Windows subsystem for Linux. When done you should have a working em++ compiler in the path:

$ em++ --version
emcc (Emscripten gcc/clang-like replacement) 1.38.16 (commit 7a0e27441eda6cb0e3f1210e6837cae4b080ab4c)

Qt for WebAssembly applications are also Emscripten-based applications. Qt makes use of many of its features and so can application code.


Next, install the Qt 5.12 sources, for example using the online installer:


Build Qt from source and specify that we are cross-compiling for wasm using emscripten:

$ ~/Qt/5.12.0/Src/configure -xplatform wasm-emscripten
$ make

This Qt build is different from standard desktop builds in two additional ways: It is a static build, and does not support threads. Depending on how your application is structured and which features you use this may pose a problem. One way to find out is to make a separate “-static -no-feature-thread” desktop Qt build, and then debug/fix any issues there. The reason this may be preferable is that the build-debug cycle is usually faster on desktop, and you have a working debugger.

Your Application

Finally, build the application. Qmake is the currently supported build system.

$ /path/to/qt-wasm/qtbase/bin/qmake
$ make

This will produce several output files:

Name Producer Purpose
app.html Qt HTML container
qtloader.js Qt JS API for loading Qt apps
app.js emscripten app runtime and JS API
app.wasm emscripten app binary

Here, the app.wasm contains the majority (if not all) of the application and Qt code, while the .js files provide loading and run-time support.

The .html file provides the html page structure which contains the application as a <canvas> element. The default version of this file displays a Qt logo during the loading and compile stage and contains a simple HTML page structure which makes the application use the entire browser viewport. You will probably want to replace this with application-specific branding and perhaps integrate with existing html content.

For qtloader.js our intention is to have a public and stable API for loading Qt-based applications, but we are not there yet and the API in that file is subject so change.

The files are plain data files and can be served from any http server; there is no requirement for any special active server component or plugin. Note that loading from the file system is not supported by current browsers. I use Python http.server for development, which works well.

When deploying applications we do recomned using a server that supports compression. The following table gives an indication of what the expected file sizes (for the main .wasm file) are:

Qt Modules gzip brotli
Core Gui 2.8MB 2.1MB
Core Gui Widgets 4.3MB 3.2MB
Core Gui Widgets Quick Charts 8.6MB 6.3MB

gzip is a good default choice as compressor and is supported by most web servers. brotli provides a nice compression gain and is supported by all wasm-enabled browsers.


The final result of all this should be your application running in a web browser, here represented by the Slate app created by my colleague Mitch. Slate is a Qt Quick Controls 2 based image editor.


A live version is available as well. If you’ve looked at this demo before the news is that it should be actually usable now: local file access is possible and there are few or none visual glitches.

For those that are attending Qt World Summit in Berlin next month: I look forward to seeing you there. If you a are not going then let me link to the webinar once again.

The post Getting Started With Qt for WebAssembly appeared first on Qt Blog.

Qt Creator 4.8 Beta2 released

We are happy to announce the release of Qt Creator 4.8.0 Beta2!

This release comes with the many fixes that we have done since our first Beta release.

Additionally we upgraded the LLVM for the Clang code model to version 7.0, and our binary packages to the Qt 5.12 prerelease.

Get Qt Creator 4.8 Beta2

The opensource version is available on the Qt download page, and you find commercially licensed packages on the Qt Account Portal. Qt Creator 4.8 Beta2 is also available under Preview > Qt Creator 4.8.0-beta2 in the online installer. Please post issues in our bug tracker. You can also find us on IRC on #qt-creator on chat.freenode.net, and on the Qt Creator mailing list.

The post Qt Creator 4.8 Beta2 released appeared first on Qt Blog.

Qt Quick Performance Improvements with Qt 5.12 LTS

We are continuously working on improving the performance and optimizing the memory consumption of Qt. One focus area for Qt 5.12 has been to reduce the memory consumption of the QML engine and tuning the JavaScript performance.

Qt 5.9 LTS already shows a great improvement of the overall performance compared to the previous long-term supported Qt 5.6 LTS release. These are summarized in a blog post about Performance Improvements with Qt 5.9 LTS and Qt Quick Performance Improvements on 64-bit ARM. With Qt 5.12 LTS we have continued to tune these further and taken a deeper look into the areas of QML engine memory consumption and JavaScript performance.

QML Memory usage

Applications use memory for multiple things and to optimize the overall memory usage a good start is typically to look into the graphics assets, leveraging asset conditioning, the Qt Lite feature system to remove unused functionality and other techniques to optimize the memory usage. As it is very difficult for an application developer to affect the memory used by the QML engine itself, we have taken a deep look into how it can be reduced.

One important optimization done with Qt 5.12 LTS are to the data structures used in conjunction with compiled QML. The QML engine creates cache files that contain a dump of internal data structures on the fly when loading a .qml or .js file at run-time (named .qmlc and .jsc). If found, these files are mapped into the application process and used directly without requiring a compilation step. We have an option to create those cache files ahead of time while compiling the application. In that case, we don’t have quite the same degree of visibility into the type system as the QML engine has at run-time. This leads to a staged approach where we can’t resolve quite as much as when generating the data structures at run time, requiring us to do some additional work on top of the pre-generated cache files.

In Qt 5.12 LTS two changes are done to reduce the memory consumption when using such ahead-of-time generated cache files:

  • Avoid the re-creation of the indexed string table for the in-memory generated compilation unit and instead fall back to the memory mapped string table provided from the cache file.
  • Reduce the size of data structures so that the size of the files as well as their memory consumption is reduced.

In addition to the changes described above, we have done also multiple smaller improvements to reduce the memory consumption of the QML engine, while still keeping the performance on a good level (and actually improving quite a bit in some areas).

Actual memory usage of a Qt Quick applications depends a lot upon the application itself. In the comparison chart below, we have measured the QML engine related memory consumption for two different applications. We have used the Qt Quick Controls example to represent a Qt Quick application.


For the example application we can see that Qt 5.6.3 uses 36.3 MB, Qt 5.9.7 uses 18.5 MB and Qt 5.12 Beta uses 13.0 MB RAM (using pre-compiled QML). This means that memory usage with Qt 5.12 is 30% lower than Qt 5.9 and 64% lower than Qt 5.6 with the example application. These savings are available for all users of Qt. For commercial users Qt 5.6 and 5.9 offered a separate tool called Qt Quick Compiler that can be used for pre-compiling QML. Using the Qt Quick Compiler, the memory usage of Qt 5.6 drops to 14.4 MB (60% lower RAM usage than without). So even when sing the Qt Quick Compiler with 5.6, upgrading to Qt 5.12 will lead to a very nice 10% improvement in memory usage.

As all applications are different it is best to check how big the benefit is for your application. We compared the QML engine memory use of Qt 5.6 and 5.9 using Qt Quick Compiler and Qt 5.12 using the pre-generated QML with a rather complex real-life Qt Quick application. In this measurement Qt 5.9 used 1.1 MB less RAM than Qt 5.6 (both with Qt Quick Compiler), and Qt 5.12 used a whopping 9.8 MB less RAM than Qt 5.6 (with Qt Quick Compiler). Especially for embedded systems with constrained resources or ones that run multiple applications this type of RAM savings in the QML engine, with no changes to the application code, are very beneficial.

JavaScript Performance

A major difference of Qt 5.12 LTS compared to Qt 5.9 LTS and Qt 5.6 LTS is the completely new compiler architecture of the QML engine introduced with Qt 5.11. The new pipeline has also enabled making some of the memory use optimizations described earlier in this post. With the new pipeline, we get a significant improvement in JavaScript performance, even with the addition of ECMAScript 7 support in Qt 5.12.

To compare the JavaScript performance for different Qt versions, we have run the same JavaScript benchmark with Qt 5.6.3, Qt 5.9.7 and Qt 5.12 Beta. The benchmark is run on 64-bit ARM processors using Linux operating system.


To highlight the improvement with Qt 5.9 and 5.12 we have normalized the result of Qt 5.6 to 100.

Overall improvement (TotalScore) of Qt 5.9 compared to Qt 5.6 is 1785% and Qt 5.12 compared to Qt 5.6 the improvement is 2187%. Compared to Qt 5.6, the biggest performance improvement is seen due to supporting JIT on 64-bit ARMv8 architecture used in many modern embedded processors. With Qt 5.6 JIT is not supported on 64-bit ARM.

Qt 5.9 and Qt 5.12 both support JIT, so between these the improvements are mainly due to the new compiler architecture. Compared to Qt 5.9 the overall JavaScript performance improvement of Qt 5.12 is 21%.

Overall Qt Quick Performance

Because it is so easy to break performance, we regularly run several different kinds of performance tests. These also help in analyzing how the various optimizations work across different platforms and to make sure feature development and error corrections do not have unintended side effects to performance. Some of these results are visible at testsresults.qt.io, for example the QML Bench tests.

To compare the effect of Qt versions, we have run the full QML Bench test set with Qt 5.6.3, Qt 5.9.7 and Qt 5.12 Beta. To improve the comparability of results, we are running Qt Quick Controls 1 tests on Qt 5.6, as it does not have Qt Quick Controls 2 functionality. Otherwise the functionality tested by the QML Bench is same between these Qt versions. For these tests, QML Bench was run on an Nvidia Jetson TX1 development board (64-bit ARM processor) running the Nvidia supported Linux for Tegra Ubuntu 16.04.

Due to the improvement in JavaScript as well as Qt Quick Controls performance is so big, we have presented those separately (JavaScript earlier in this post and Qt Quick Controls in an earlier blog). We have again normalized the Qt 5.6.3 result to be 100 in order to better highlight the improvements with Qt 5.9 and Qt 5.12.


For the overall QML Bench test the performance with Qt 5.9 is double compared Qt 5.6 (109% better than Qt 5.6), and the performance of Qt 5.12 is on the same level (98% better than Qt 5.6). The improvements in areas other than JavaScript and Qt Quick Controls are smaller, typically between 15 to 25%. Comparing Qt 5.9 and Qt 5.12 gives a bit more of a mixed picture. While there are quite some areas where performance is better with Qt 5.12, we are also seeing performance regressions in a couple of test cases. Those regressions are things we will have examine closer over the next couple of months and want to improve upon in patch level release for Qt 5.12.

Note that QML Bench is not directly representative of the real-life application performance. Each application uses different QML functions, typically some multiple times. QML Bench on the other hand uses all of the functionality rather equally and does not weight results according to frequency of use in the real world – so it is always recommended to gather performance data with your own application to see how much its performance improves.

Other improvements

In this post the focus was in the Qt Quick performance, where we have improved the performance of Qt 5.12 LTS significantly compared to the earlier LTS releases of Qt in three important areas:

  • QML memory usage
  • Overall Qt Quick performance
  • JavaScript performance

In addition to these, Qt 5.12 LTS provides many other performance improvements as well. One important improvement in Qt 5.12 LTS is the possibility to use pre-generated distance fields of fonts. Earlier Qt has created the distance fields during the application startup, which can consume a lot of CPU cycles especially for non-latin fonts (that have many glyphs) and complex latin fonts (that have a lot of different shapes). With Qt 5.12 LTS, we release a tool called “Qt Distance Field Generator”, which allows you to pregenerate the distance fields for either a selection of the glyphs in a font or all of them.

Other areas where we have been improving performance include, for example, Qt 3D CPU usage and Qt 3D memory consumption (especially beneficial for Qt 3D Studio applications). Qt 5.12 LTS also introduces a completely re-designed TableView, which takes the performance of large tables to completely different level than the old TableView implementation of Qt Quick Controls 1. Of course, Qt 5.12 LTS also benefits from the compressed texture support introduced with Qt 5.10 and improved with Qt 5.11, as well as multiple other improvements done since the previous LTS release of Qt.

Qt 5.12 LTS is currently in Beta phase and we are working hard to get the Qt 5.12.0 release out at the end of November. If you have not yet looked into Qt 5.12 LTS, please take it for a spin.



The post Qt Quick Performance Improvements with Qt 5.12 LTS appeared first on Qt Blog.

Python and Qt: 3,000 hours of developer insight

With Qt for Python released, it’s time to look at the powerful capabilities of these two technologies. This article details one solopreneur’s experiences.

The task

Back in 2016, I started developing a cross-platform file manager called fman. Its goal: To let you work with files more efficiently than Explorer on Windows or Finder on Mac. If you know Total Commander and Sublime Text, a combination of the two is what I am going for. Here’s what it looks like:

fman screenshot

Picking technologies for a desktop app

The biggest question, in the beginning, was which GUI framework to use. fman’s choice needs to tick the following boxes:

  • Cross-platform (Windows, Mac, Linux)
  • Good performance
  • Support for custom styles
  • Fast development

At the time, Electron was the most-hyped project. It has a lot of advantages: You can use proven web technologies. It runs on all platforms. Customizing the UI of your application is trivial by means of CSS. Overall, it’s a very powerful technology.

The big problem with Electron is performance. In particular, the startup time was too high for a file manager: On an admittedly old machine from 2010, simply launching Electron took five seconds.

I admit that my personal distaste for JavaScript also made it easier to discount Electron. Before I go off on a rant, let me give you just one detail that I find symptomatic: Do you know how JavaScript sorts numbers? Alphabetically. ’nuff said.

After considering a few technologies, I settled on Qt. It’s cross-platform, has great performance and supports custom styles. What’s more, you can use it from Python. This makes at least me orders of magnitude more productive than the default C++.

Writing a GUI with Python and Qt

Controlling Qt from Python is very easy. You simply install Python and use its package manager to fetch the Qt bindings. Gone are the days where you had to set up gigabytes of software, or even Qt. It literally takes two minutes. I wrote a Python Qt tutorial that shows the exact steps and sample code if you’re interested.

You can choose between two libraries for using Qt from Python:

  • PyQt is mature but requires you to purchase a license for commercial projects.
  • Qt for Python is a recent push by Qt the company to officially support Python. It’s offered under the LGPL and can thus often be used for free.

From a code perspective, it makes no difference because the APIs are virtually identical. fman uses PyQt because it is more mature. But given that Qt for Python is now officially supported, I hope to switch to it eventually.

Deploying to multiple platforms

Once you’ve written an application with Python and Qt, you want to bring it into the hands of your users. This turns out to be surprisingly hard.

It starts with packaging. That is, turning your source code into a standalone executable. Special Python libraries exist for solving this task. But they never “just work”. You may have to manually add DLLs that are only required on some Windows versions. Or avoid shipping shared libraries that are incompatible with those already present on the users’ systems. Or add special handling for one of your dependencies. Etc.

Then come installers. On Windows, most users expect a file such as AppSetup.exe. On Mac, it’s usually App.dmg. Whereas on Linux, the most common file formats are .deb.rpm and .pkg.tar.xz. Each of these technologies takes days to learn and set up. In total, I have spent weeks just creating fman installers for the various platforms.

Code signing

By default, operating systems show a warning when a user downloads and runs your app:

To prevent this, you need to code sign your application. This creates an electronic signature that lets the OS verify that the app really comes from you and has not been tampered with. Code signing requires a certificate, which acts like a private encryption key.

Obtaining a certificate differs across platforms. It’s easiest on Linux, where everyone can generate their own (GPG) key. On Mac, you purchase a Developer Certificate from Apple. Windows is the most bureaucratic: Certificate vendors need to verify your identity, your address etc. The cheapest and easiest way I found was to obtain a Comodo certificate through a reseller, then have them certify my business – not me as an individual.

Once you have a certificate, code signing involves a few more subtleties: On Windows and Ubuntu, you want to ensure that SHA256 is used for maximum compatibility. On Linux, unattended builds can be tricky because of the need to inject the passphrase for the GPG key. Overall, however, it’s doable.

Automatic updates

Like many modern applications, fman updates itself automatically. This enables a very rapid development cycle: I can release multiple new versions per day and get immediate feedback. Bugs are fixable in less than an hour. All users receive the fix immediately, so I don’t get support requests for outdated problems.

While automatic updates are a blessing, they have also been very expensive to set up. The tasks we have encountered so far – packaging, installers and code signing – took a month or two. Automatic updates alone required the same investment again.

The most difficult platform for automatic updates was Windows. fman uses a Google technology called Omaha, which is for instance used to update Chrome. I wrote a tutorial that explains how it works.

Automatic updates on Mac were much easier thanks to the Sparkle update framework. The main challenge was to interface with it via Objective-C from Python. Here too I wrote an article that shows you how to do it.

Linux was “cleanest” for automatic updates. This is because modern distributions all have a built-in package manager such as apt or pacman. The steps for enabling automatic updates were typically:

  • Host a “repository” for the respective package manager. This is just a collection of static files such as .deb installers and metafiles that describe them.
  • Upload the installer to the repository, regenerating the metafiles.
  • Create a “repository file”: It imports the repo into the user’s package manager.

Because fman supports four Linux distributions, this still required learning quite a few tools. But once you’ve done it for two package managers, the others are pretty similar.

OS Versions

There aren’t just different operating systems, there are also different versions of each OS. To support them, you must package your application on the earliest version. For instance, if you want your app to run on macOS 10.10+, then you need to build it on 10.10, not 10.14. Virtual machines are very useful for this. I show fman’s setup in a video.

fman’s build system

So how does fman cope with all this complexity? The answer is simple: A Python-based build script. It does everything from creating standalone executables to uploading to an update server. I feel strongly that releasing a desktop app should not take months, so am making it available as open source. Check it out if you are interested!


Python and Qt are great for writing desktop apps: Qt gives you speed, cross-platform support and stylability while Python makes you more productive. On the other hand, deployment is hard: Packaging, code signing, installers, and automatic updates require months of work. A new open source library called fbs aims to bring this down to minutes.

If you liked this post, you may also be interested in a webinar Michael is giving on the above topics. Sign up or watch it here: Americas / EMEA

The post Python and Qt: 3,000 hours of developer insight appeared first on Qt Blog.

Future Developments in clang-query

Getting started – clang-tidy AST Matchers

Over the last few weeks I published some blogs on the Visual C++ blog about Clang AST Matchers. The series can be found here:

I am not aware of any similar series existing which covers creation of clang-tidy checks, and use of clang-query to inspect the Clang AST and assist in the construction of AST Matcher expressions. I hope the series is useful to anyone attempting to write clang-tidy checks. Several people have reported to me that they have previously tried and failed to create clang-tidy extensions, due to various issues, including lack of information tying it all together.

Other issues with clang-tidy include the fact that it relies on the “mental model” a compiler has of C++ source code, which might differ from the “mental model” of regular C++ developers. The compiler needs to have a very exact representation of the code, and needs to have a consistent design for the class hierarchy representing each standard-required feature. This leads to many classes and class hierarchies, and a difficulty in discovering what is relevant to a particular problem to be solved.

I noted several problems in those blog posts, namely:

  • clang-query does not show AST dumps and diagnostics at the same time<
  • Code completion does not work with clang-query on Windows
  • AST Matchers which are appropriate to use in contexts are difficult to discover
  • There is no tooling available to assist in discovery of source locations of AST nodes

Last week at code::dive in Wroclaw, I demonstrated tooling solutions to all of these problems. I look forward to video of that talk (and videos from the rest of the conference!) becoming available.

Meanwhile, I’ll publish some blog posts here showing the same new features in clang-query and clang-tidy.

clang-query in Compiler Explorer

Recent work by the Compiler Explorer maintainers adds the possibility to use source code tooling with the website. The compiler explorer contains new entries in a menu to enable a clang-tidy pane.

clang-tidy in Compiler Explorer

clang-tidy in Compiler Explorer

I demonstrated use of compiler explorer to use the clang-query tool at the code::dive conference, building upon the recent work by the compiler explorer developers. This feature will get upstream in time, but can be used with my own AWS instance for now. This is suitable for exploration of the effect that changing source code has on match results, and orthogonally, the effect that changing the AST Matcher has on the match results. It is also accessible via cqe.steveire.com.

It is important to remember that Compiler Explorer is running clang-query in script mode, so it can process multiple let and match calls for example. The new command set print-matcher true helps distinguish the output from the matcher which causes the output. The help command is also available with listing of the new features.

The issue of clang-query not printing both diagnostic information and AST information at the same time means that users of the tool need to alternate between writing

set output diag


set output dump

to access the different content. Recently, I committed a change to make it possible to enable both output and diag output from clang-query at the same time. New commands follow the same structure as the set output command:

enable output dump
disable output dump

The set output <feature> command remains as an “exclusive” setting to enable only one output feature and disable all others.

Dumping possible AST Matchers

This command design also enables the possibility of extending the features which clang-query can output. Up to now, developers of clang-tidy extensions had to inspect the AST corresponding to their source code using clang-query and then use that understanding of the AST to create an AST Matcher expression.

That mapping to and from the AST “mental model” is not necessary. New features I am in the process of upstreaming to clang-query enable the output of AST Matchers which may be used with existing bound AST nodes. The command

enable output matcher

causes clang-query to print out all matcher expressions which can be combined with the bound node. This cuts out the requirement to dump the AST in such cases.

Inspecting the AST is still useful as a technique to discover possible AST Matchers and how they correspond to source code. For example if the functionDecl() matcher is already known and understood, it can be dumped to see that function calls are represented by the CallExpr in the Clang AST. Using the callExpr() AST Matcher and dumping possible matchers to use with it leads to the discovery that callee(functionDecl()) can be used to determine particulars of the function being called. Such discoveries are not possible by only reading AST output of clang-query.

Dumping possible Source Locations

The other important discovery space in creation of clang-tidy extensions is that of Source Locations and Source Ranges. Developers creating extensions must currently rely on the documentation of the Clang AST to discover available source locations which might be relevant. Usually though, developers have the opposite problem. They have source code, and they want to know how to access a source location from the AST node which corresponds semantically to that line and column in the source.

It is important to make use a semantically relevant source location in order to make reliable tools which refactor at scale and without human intervention. For example, a cursory inspection of the locations available from a FunctionDecl AST node might lead to the belief that the return type is available at the getBeginLoc() of the node.

However, this is immediately challenged by the C++11 trailing return type feature, where the actual return type is located at the end. For a semanticallly correct location, you must currently use


It should be possible to use getReturnTypeSourceRange(), but a bug in clang prevents that as it does not appreciate the trailing return types feature.

Once again, my new output feature of clang-query presents a solution to this discovery problem. The command

enable output srcloc

causes clang-query to output the source locations by accessor and caret corresponding to the source code for each of the bound nodes. By inspecting that output, developers of clang-tidy extensions can discover the correct expression (usually via the clang::TypeLoc heirarchy) corresponding to the source code location they are interested in refactoring.

Next Steps

I have made many more modifications to clang-query which I am in the process of upstreaming. My Compiler explorer instance is listed as the ‘clang-query-future’ tool, while the clang-query-trunk tool runs the current trunk version of clang-query. Both can be enabled for side-by-side comparison of the future clang-query with the exising one.

Testing Qt on Emulated Architectures Using QEMU User Mode

by Allan Sandfeld Jensen (Qt Blog)

Have you ever wanted to test if your application works on ARM, but don’t want to make an image and launch a real device, or wanted to test an architecture you don’t even have hardware for? I have been following a set of instructions I have gathered from various online sources, and have been teaching others how to do the same, but I want to collect it all here and publish it here for you to follow as well. While writing this I will be following the instructions myself for an architecture I haven’t done this for before.

The secret is of course QEMU, but to make testing easier I will set it up so that QEMU doesn’t simulate an entire system, but runs foreign applications as if they were native inside my existing X11 desktop. This is possible through the qemu-user binaries, which can run statically linked executables or dynamically linked ones if you are in a properly set up chroot.

Setting up chroot

So how do you get this properly set up chroot? There are various ways depending on the Linux distro. I personally use Debian, and the instructions here will be almost identical to what is done on Ubuntu. If you use Suse or RedHat, I know you can find official guidelines on setting up a chroot for qemu.

First, get the dependencies (as root or sudo) :
apt-get install binfmt-support qemu qemu-user-static debootstrap

Most of these are just the tools needed, and binfmt-support is configuration glue what will make Linux launch ELF executables with non-native architectures using qemu, which is another piece of the magic puzzle.

For my example I am testing while writing this, I will be targeting the IBM mainframe architecture S/390x and will also need the cross-building tools for that as well. I can get all of those on Debian by just pulling in the right cross-building g++ (as root or sudo) :
apt-get install g++-s390x-linux-gnu

S/390x is interesting for me because Debian dropped official support for big endian PPC64, so I need a new way of testing that Qt works on 64bit big-endian platforms.

Now go to where you want your sysroots installed, and run debootstrap. Debootstrap is the Debian tool for downloading and installing a Debian image into a sub-directory
(as root or sudo) :
debootstrap stable --arch s390x stable debian-s390x http://deb.debian.org/debian/

Next prepare it for being a chroot system (as root or sudo) :
mount --rbind /dev debian-s390x/dev/
mount --rbind /sys debian-s390x/sys/
mount --rbind /proc debian-s390x/proc/

Enter the chroot (as root or sudo) :
chroot debian-s390x

If you run ‘uname -a’ here you will now get something like:
Linux hostname 4.x.x-x-amd64 #1 SMP Debian 4.x.x-x (2018-x-x) s390x GNU/Linux

In other words, a native AMD64 kernel with x390x userland! Every command you execute here will be using s390x binaries in the chroot, but using the native kernel for system calls. If you launch an X11 app, it will be using the X11-server running natively on your machine already.

Prepare chroot to be a sysroot

To build Qt, we also need all the Qt dependencies inside the chroot. In Debian we can do that using ‘apt-get build-dep’.

Edit debian-s390x/etc/apt/sources.list and add a deb-src line, such as:
deb-src http://deb.debian.org/debian stable main

Install the Qt dependencies (inside chroot as root):
apt-get update
apt-get build-dep qtbase-opensource-src

Finally, for the setup we need to make sure it works a sysroot for cross-building by replacing absolute links to system libraries with relative ones that work both inside and outside the chroot (inside chroot as root):
apt-get install symlinks
cd /usr/lib/
symlink -rc .

Building Qt

We can now build Qt for this sysroot. If you want to test you own applications, you could also install an official prebuilt Qt version from Debian, and build against that.

Configuring Qt for cross-building to a platform like that looks like this on Debian, and only needs a few changes to work on other platforms:
$QTSRC/configure -prefix /opt/qt-s390x -release -force-debug-info \
-system-freetype -fontconfig -no-opengl \
-device linux-generic-g++ -sysroot /sysroots/debian-s390x \
-device-option CROSS_COMPILE=/usr/bin/s390x-linux-gnu-

You can remove the -no-opengl argument if you want to test OpenGL using the mesa software implementation, but otherwise I don’t recommend using OpenGL inside the chroot.

If everything is setup correctly you don’t need to specify ‘-system-freetype -fontconfig’. It is just there to catch failures in pkg-config, so we don’t end up building a Qt version that requires manually bundling fonts.

In general cross-compiling with Qt always looks similar to the above, but note that if you are cross-building to ARM32, it looks a little bit different:
$QTSRC/configure -prefix /opt/qt-armhf -release -force-debug-info \
-system-freetype -fontconfig -no-opengl \
-device linux-arm-generic-g++ -sysroot /sysroots/debian-armhf \
-device-option DISTRO_OPTS=hard-float \
-device-option COMPILER_FLAGS='-march=armv7-a -mfpu=neon' \
-device-option CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf-

Notice that ARM32 has a specific device name (linux-arm-generic-g++ instead of linux-generic-g++) and needs to have a floating-point mode set. Additionally, for older embedded architectures, it is generally a good idea to specify COMPILER_FLAGS to select a specific architecture. You need to pass compiler flags as a device-option, because the normal way of specifying QMAKE_CFLAGS and QMAKE_CXXFLAGS after configure options sets the host compiler flags, not the target compiler flags. If you need more complicated options, you should make your own qmake device target. You can always base it of linux-generic-g++ for good defaults.

With Qt configured like this, you can build it as usual and run make install to have the libraries installed into the /opt directory under the chroot.

Issue encountered; as I built qtbase, I hit a linking error:
qt5/qtbase/src/corelib/global/qrandom.cpp:143: error: undefined reference to 'getentropy'

The problem turns out to be that my cross-building tools have libc6 2.27 while the sysroot has libc6 2.24. The best thing to do would be using the same libc version on both sides. However, as they are fully compatible, except for newer features in one, I chose to just disable this feature in Qt. I accomplished this by calling the configure command again, this time with -no-feature-getentropy added.

With this change, everything I tried building built and installed without further issues.

Run a Qt application

To get some examples to test, go to the folder of the example in the build tree and run ‘make install’. For instance, my standard example for widgets:
cd qtbase/examples/widgets/richtext/textedit
make install

Then (inside chroot as root, assuming you have created a testuser):
su - testuser
export DISPLAY=:0
/opt/qt-s390x/examples/widgets/richtext/textedit/textedit -platform xcb

And it just works…
The -platform xcb argument is needed because the default for embedded builds is using the eglfs QPA. I am assuming you are developing on X11 and want the jaw-dropping experience of having a foreign architecture Qt application just launch like a normal Qt app.

In this setup, the applications running in QEMU will be much faster than under a full system emulation, because the kernel and the X11 server are still the native ones, and thus running at normal speed. However, for X11 it means sometimes having a few oddities, as there can be client-server mismatch in endianness. While it is supposed to be supported, it is such an edge case that it often has issues. This is the reason why QT_XCB_NO_MITSHM=1 is set. Otherwise, we would hit an issue with passing file descriptors between client and server, which is likely a bug in libxcb. If we were testing a little-endian architecture like arm64 or riscv instead, the environment variable would not be needed.

So that is it, quite a few steps, but most only done once. And as I wrote this, I followed the same instructions for a rather uncommon and not officially supported platform, and only hit two issues with easy work-arounds.

The post Testing Qt on Emulated Architectures Using QEMU User Mode appeared first on Qt Blog.

Qt on macOS 10.14 Mojave

by Morten Johan Sørvig (Qt Blog)

The newest version of macOS 10.14 has now been released and this time there are two major changes that affect Qt applications: Core Animation (CA) layer backing is enabled for all native views, and dark mode has been introduced. We’ve been testing on the betas since this summer, those who follow Qt development closely might have seen the commits.

The Qt release target for the fixes is the 5.12 branch, which has a couple of implications for Qt users:

  • We encourage upgrading to Qt 5.12 to get fixes for macOS 10.14
  • The maximum supported Xcode version for Qt 5.11 and lower is Xcode 9 (SDK 10.13)

The latter point may require further explanation. New features such as Dark Mode, or behavior changes such as CA layer backing are gated on the SDK version used to link the application. This provides a compatibility mode for existing binaries and for code bases that have not yet been updated.

This workaround of using an older Xcode and SDK version also applies when using Qt 5.12, if you encounter a bug related to dark mode or layer backing that we have not fixed in Qt.

For more information, se the Qt for macOS documentation.

The post Qt on macOS 10.14 Mojave appeared first on Qt Blog.

Release 2.18.2: Guide for MVC, MVVM, Flux with QML

V-Play 2.18.2 adds the latest Qt Creator 4.7, as well as many improvements and fixes. A new comprehensive guide helps you to structure your code, and separate logic from UI. The guide comes with a list of best practice examples, which you can also check out in our open source example apps.

Separation of Model, View and Logic (MVC, MVVM, Flux) Tutorial for QML

Separation of concerns is a key factor to improve your project, to get a clean and maintainable code structure. Many concepts offer different approaches on this topic, popular examples are MVC, MVVM and Flux.

This V-Play update adds a new comprehensive developer guide: Separation of Model, View and Logic Code in your App. The guide offers a best-practice solution how to separate model, view and logic components in your V-Play apps:


Important topics covered in this guide are:

  • Why care about separation of concerns?
  • Create a Clean Data Flow
  • Application Logic
  • DataModel and Storage
  • Pages and View Logic


You can now also start from a new project template, that already includes the skeleton code for such a separation. For any data-driven application, especially if you connect e.g. REST APIs, this will be a great starting point:


Improved Toolchain with Qt Creator 4.7

This version of Qt Creator adds many improvements and new features. V-Play 2.18.2 ships this new version of Qt Creator by default, if you update or install V-Play.

Here are some of the changes with Qt Creator 4.7:

  • Improved performance and stability
  • Clang code model enabled by default
    • Support for C++17, likely new warnings (“fixits”) will show up in code editor now
    • Hover an ‘auto’ variable and the real type will show up
  • New analyze & refactoring tools: Clang-Tidy and Clazy
  • Filesystem navigation: Quickly browse folders with new clickable breadcrumbs
  • Model Editor enabled by default, create a visual code/class structure with it
  • New files are now added to the correct project and show up in the project view
  • ‘Run Test Under Cursor’ is now available when the cursor is inside a text method
  • Qt Kit settings category is now the most top option
  • (HiDPI) Scaling for Qt Creator can now be toggled in settings

Important Note for Release Builds

The new Qt Creator enables the Qt Quick Compiler by default if you create a release build and enable the resource system to protect your source code. The Qt Quick Compiler requires each file to be referenced in a resource file. If you have a look at your V-Play project, you will find a resources.qrc file. By default, it only references the qml folder, which is enough to use the resource system to protect your source code files. If you also want to use the Qt Quick Compiler, which is enabled by default with the new Qt Creator, you need to reference every single file of your qml folder.

You can also disable the Qt Quick Compiler in the project settings in Qt Creator or add this line to your *.pro file: CONFIG -= qtquickcompiler

You can find more information on this topic in our documentation.

More Features, Improvements and Fixes

Here is a compressed list of further improvements with this update:

For a list of additional fixes, please check out the changelog.




More Posts Like This


Machine Learning: Add Image Classification for iOS and Android with Qt and TensorFlow

Qt AR: Why and How to Add Augmented Reality to Your Mobile App
Qt AR: Why and How to Add Augmented Reality to Your Mobile App

Release 2.18.1: Use JavaScript Promises with Qt, Material Cards and an Improved API to Connect to REST Services

Release 2.18.0: Update to Qt 5.11.1 with QML Compiler and Massive Performance Improvements

How to Make Cross-Platform Mobile Apps with Qt – V-Play Apps

The post Release 2.18.2: Guide for MVC, MVVM, Flux with QML appeared first on V-Play Engine.

Sharing Files on Android or iOS from or with your Qt App – Part 4

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

Welcome to Part 4 of my Blog series about Sharing Files to and from mobile Qt Apps.

Part 1  was about sharing Files or Content from your Qt App with native Android or iOS Apps,
Part 2 explained how to share Files with your Qt App from other native Android Apps,
Part 3 covered sharing Files with your Qt App from other native iOS Apps.
Part 4 implements FileProvider to share Files from your Qt App with native Android  Apps.



FileProvider Content URIs

Starting with Android 7 (SDK 24) you cannot use File URIs anymore to share Files to other Android Apps – you must use a FileProvider to share Files using a Content URI.

To avoid this you could use Target SDK 23 as I did for the first parts of this blog.

But starting November 1, 2018 Google requires for updates to Apps or new Apps on Google Play to target Android 8 (Oreo, API level 26) or higher, so there’s no way to share Files on Android without using a FileProvider.

Here’s the workflow to update your sharing App from File URI to FileProvider with Content URI.

 Android Manifest

As a first step we have to add some info to AndroidManifest.xml :

<application ...>
<provider android:name="android.support.v4.content.FileProvider"
android:grantUriPermissions="true" android:exported="false">
<meta-data android:name="android.support.FILE_PROVIDER_PATHS"

The Provider needs the com.android.support.v4 Libraries. To include them, please add com.android.support to your build.gradle file:






This will only work if you have installed the Android Support Repository.

In your QtCreator Preferences → Devices → Android, you get easy access to Android SDK Manager. Please check that under Extras the Android Support Repository is installed:


In your Android Manifest you see a reference to resources @xml/filepaths. You have to add a new File filepaths.xml under android/res/xml:


The content of filepaths.xml:

<paths xmlns:android="http://schemas.android.com/apk/res/android">
<files-path name="my_shared_files" path="share_example_x_files/" />

This is the mapping to the folder where Android will find your File to be shared. This Folder is inside your AppData Location. Remember: in blog part 1 we used a shared documents location to provide Files to other apps. Now for Android we don’t use a shared location but a path inside our AppData location. Starting the app I always check if the folder exists:


#if defined (Q_OS_IOS)
QString docLocationRoot = QStandardPaths::standardLocations(QStandardPaths::DocumentsLocation).value(0);
#if defined(Q_OS_ANDROID)
QString docLocationRoot = QStandardPaths::standardLocations(QStandardPaths::AppDataLocation).value(0);
mDocumentsWorkPath = docLocationRoot.append("/share_example_x_files");
if (!QDir(mDocumentsWorkPath).exists()) {
// create the QDir


Last important part in Android Manifest specifies an Authority:


This name must be unique – so it’s a good idea to use your package name and append .fileprovider.

 QShareUtils Java Code

As a last step you must do some small changes in QShareUtils.java.

Import FileProvider and ShareCompat from android.support:

import android.support.v4.content.FileProvider;

import android.support.v4.app.ShareCompat;

Reference the Authority as defined in AndroidManifest:

private static String AUTHORITY="org.ekkescorner.examples.sharex.fileprovider";

You must also create your Intents in a different way:

// the old way: Intent sendIntent = new Intent();

Intent sendIntent = ShareCompat.IntentBuilder.from(QtNative.activity()).getIntent();

You’re done 🙂

As a positive side effect, it’s now much safer to share Files because they are inside your App Sandbox located and not in public shared Folder.


Here‘s a short Overview about the Android FileProvider implementation:



Some issues from Sharing Files to other Android Apps

Android: Sharing to Google Fotos App

If you try to edit an Image in Google Fotos App using the FileProvider, the Fotos App appears in the list of available Apps, but then reports that the File cannot be edited. Viewing works as before.

Only current workaround is to use another Foto Editing App.


Thanks again to Thomas K. Fischer @taskfabric for his valuable input on this topic.

Have Fun

In the first part of this blog series, I told you that I needed sharing between Apps on Android and iOS for a DropBox – like customer App. This App is running very well since some months as inHouse App at customer site, so it’s not publicly available. But my example App is Open Source and now it‘s a good time to download current Version from Github, build and run the Sharing Example App.

This was the last part of this blog series, but stay tuned for some other blogs about „Qt mobile Apps in the Enterprise“ and „QML Camera on Android and iOS“.

The post Sharing Files on Android or iOS from or with your Qt App – Part 4 appeared first on Qt Blog.

What’s New in Qt Help?

We have made visible and invisible changes to the Qt Help module in the 5.9 and 5.12 branches, which influence the behavior of both Qt Creator’s Help mode and Qt Assistant.

What’s new in Qt Help in 5.9?

The most important changes to the Qt Help module in Qt 5.9 were replacing the CLucene search engine with SQLite with FTS5 mode turned on and fixing the documentation indexing.

Replacing the search engine

Internally, Qt Help used the CLucene third party code for full-text search functionality. However, the CLucene lib has not been actively maintained since a couple of years, and therefore possible bugs for CLucene have not been resolved. Also, the CLucene code base is getting older every year, and modern compilers raise more and more warnings when trying to compile it.

Switching to the SQLite database did not mean adding extra third party code to Qt, because SQLite is already included in Qt and the Qt Help module is already using it. Removing CLucene removed about 60.000 LOC from Qt sources for CLucene itself and replaced about 3.000 lines of glue code between Qt Help and CLucene. In comparison, only about 650 lines of glue code between Qt Help and SQLite’s FTS5 had to be added. Comparing these numbers to the current size of the Qt Help library itself, which is about 10.000 LOC in total, the decrease of LOC is really huge. The smaller the code base, the better. From maintenance point of view, this looks like a good move.

Additional benefits include faster and easier compilation of the Qt Help module, which affects all developers building Qt themselves. Further, the binary files that are generated are smaller in size, which affects all users of Qt and Qt Creator.

The replacement of the full-text search engine improved not only the maintenance efforts, invisible at the first glance. There are also more visible consequences, like elimination of random crashes when using text search functionality or getting more reliable search results after adding or removing documentation files.

Simpler user interface

In addition, we have made searching easier. We have replaced the Advanced search GUI interface, with many fields, with just one simple line edit, where the user may specify queries using the AND, OR, or NOT operators or use quotations to search for multi-word expressions. For example, to search for documents containing at least one occurrence of the word six or seven and at least one occurrence of eleven or twelve, we could write the following query: (six OR seven) AND (eleven OR twelve). Before, it was not possible to mix OR and AND operators in one query.

Search results snippets

Another useful feature of the new search engine is the ability to display the search results within short text snippets, showing the context of the actual results. Before, the search results displayed a document address of the result that usually was not very useful to the user. Currently, we display an excerpt from the documentation file containing the queried word or phrase.

The search line edit in Qt 5.9. The search results display text snippets.

The Advanced Search GUI in Qt 5.8. The search results display an URL.

Fixing the documentation indexing

The other visible change in Qt Help was fixing the documentation indexing. Even though the indexing was slightly faster before than after the fix, it did not produce reliable content for the search results. This is noticeable when trying to search for the terms “charset” or “UTF-8”. Because the indexing was inaccurate, all documents would match the queries above. However, when viewing the results, no document actually contained the queried word.

Invisible changes

Apart from the visible changes in the GUI or behavior, many changes have been done internally, such as replacing the old string based connections with …, with … [Not fun getting old, my friend. How was that new typed connection style called again? I’ll search for string based connection. Let’s ask uncle G. The first result is c# – Use different connection string based on the application url…. No, that’s not what I was looking for. OK, let’s try Qt Help 5.8. The result is QSqlDatabase Class. Hmm, no, wrong hit. So, let’s try again using Qt Help 5.9. The result is Differences between String-Based and Functor-Based Connections. Wow! That’s what I was looking for! No, wait… Where is this result on uncle’s and Qt Help 5.8 lists? The uncle has it listed as the fourth hit, while in the Qt Help results it’s listed as the… 12th hit! Looks like the new search engine is doing its job! I need to remember to mention it in the blog. Cool, I may now finish my sentence:] … with functor-based connections, replacing Java-style iterators with faster STL-style iterators, and other code modernization.

What’s new in Qt Help in 5.12?

The most important changes in the Qt Help module in version 5.12 are that QHelpEngine doesn’t keep every registered .qch file open anymore and that it not detects the version numbers of documentation files.

Closing registered help files

Let’s imagine that a user of Qt Creator has installed 10 different Qt versions. Each Qt version comes with a documentation set consisting of about 60 .qch files. This means that the Qt Help integrated in Qt Creator has been keeping track of about 600 open-file descriptors at a time! On some platforms, this number may exceed the maximal allowed number for the open-file descriptors per process. Certainly, it was a real issue.

Starting from Qt 5.12, Qt Help keeps a small cache inside the help collection file for all registered documentation files. The help engine updates the cache upon every registration or de-registration of the documentation files. Qt Help opens .qch files only on demand and closes them immediately after getting the data. This way, when Qt Help needs to return the index or content results, it doesn’t need to keep all the .qch files open. This also speeds up returning these results.

Detecting documentation version numbers

If documentation files cross-reference each other and the user installed many documentation versions, clicking on such a cross-reference link usually resulted in showing the correct page, but its version didn’t match the version of the source page. We have solved this issue in the Qt Help 5.12 branch.

Other fixes

Another annoying bug that is fixed in 5.12 is the order of content items inside the Contents view. Before, the order was rather arbitrary, depending in some way on the order of registration of documentation files. Currently, content items are sorted alphabetically.

The Contents view in Qt 5.12. Items are sorted alphabetically.

The Contents view in Qt 5.9. Items are in arbitrary order.

In addition, we have done some cleanups in version 5.12. We got rid of an ancient porting tool called qhelpconverter. We have merged the qcollectiongenerator tool into the qhelpgenerator, which now accepts both .qhp and .qhcp files as input and generates .qch and .qhc files, respectively.


Not fun getting old, my friend. I’ve forgotten to mention that there is quite a big chance that you’ll get better results for your search queries starting from Qt Help 5.9, compared with the previous versions. Try searching for e.g. “QHelpEngine”. 🙂

The post What’s New in Qt Help? appeared first on Qt Blog.

Docker-based test servers for network-related Qt autotests

The existing network test server has had limitations for years. Most notably, it is only available in Qt intranet. it is not accessible by Qt developers to run network tests from outside. Since the old network test server can’t easily be reproduced, the contributor relies on Qt CI to verify and debug their changes.

As for Qt internally, the server configurations are out of date and hard to be maintained. Apparently the network code and tests are out of sync. That’s why the test server doesn’t work with many legacy tests. It makes those tests blacklisted. Even we desire to do something, it is no way to remove the blacklist. Moreover, some services (e.q. Samba) don’t allow simultaneous access. When more than one virtual machine are running the test at the same time, flaky result occurs occasionally. (what a nightmare, sigh!)

Replace the monolithic test server with Docker containers

The challenge is that it needs not only consideration for the user environments but also the test framework of Qt. We want to make it ease to use for the developers., but we need to compromise under the current test framework.

After countless discussions, we have managed to make it works on both Ubuntu and macOS.  The developers can now test networking code by using local containers to run the test servers. Besides, Qt CI is doing the test of QNetworkReply with it. If nothing unexpected happens, the Windows system with MinGW compiler is coming soon.

Requirements from developers

  1. Launch the relevant infrastructure transparently when doing make check
  2. Minimal setup required without modifying host settings (e.q. /etc/hosts)
  3. Test network code locally without login Qt intranet
  4. Provide a constant environment for each test
  5. Split the monolithic test server into several dedicated services
  6. Use Gerrit to review tests and the corresponding server configurations in the same space
  7. Progressively convert tests from using the old server to using the new approach one by one
  8. The server configurations vary depending on the repository branches
  9.  Support Qt shadow builds as well


Requirements from Qt CI

  1. Coin loses network connectivity after provisioning
  2. Cache the provisioned images so that Coin won’t rebuild the images every time
  3. Run tests in parallel to speed up the process when staging changes
  4. The side-effect shall be completely isolated if the tests are using the same service at the same time


NOTE: To learn more about how to rework existing tests and create new test servers, https://wiki.qt.io/Network_Testing.

How to run tests

Just try it, and then you will see how it works!

The container-based solution shall launch itself transparently when building check target. If the user has installed docker engine on the host, the test servers will be built up inside separate docker containers, and then, the test case goes with the docker-based test servers. Otherwise, the tests will keep using the internal test server.

bash: ~/qtbase/tests/auto/network/access/qnetworkreply (dev)
$ make check


Before starting the test servers, it requires the user to run the provisioning script in advance. The provisioning script is used to build up the docker images into the docker-cache. It handles the immutable parts of the server installation that rarely need adjustment.


What happened in the box


(1) Ensure that the docker images have been provisioned. If you get the massage below, please run the provisioning script, and then try again.

  • Docker machine qt-test-server not found
  • Docker image qt-test-server-* not found

(2) Use docker-compose to bring up the depending test servers

(3) Build test code with the predefined macro QT_TEST_SERVER

(4) Use mDNS to retrieve the IP address of each server and make sure their services are ready, and then start running test

(5) Destroy test servers and tidy away related files

Future works

It is not the perfect right now. There are still some works to be done. However, this is the first step, as well as the foundation that we can make it better step by step.

  1. Support multistage provisioning. Provision the test data in qtbase.
  2. Use Vagrant Docker provisioner to replace Boot2Docker



The post Docker-based test servers for network-related Qt autotests appeared first on Qt Blog.

Looking for Qt Champions 2018

Who do you think should be a Qt Champion? Nominate the champions you know right now!

It is that time of year again as we are in November and therefore time to look back at 2018 and think about who helped you out most during the past year.

In case you have forgotten, Qt Champions are the people in the community who go above and beyond the normal activity in the community, and contribute in some form every time. They are the stars that make you feel at home.

It’s time to nominate the Qt Champions for 2018. Please take a minute to think and fill in the name and reasons you think this person is a Qt Champion.

Qt Champions can be found in all parts of the Qt Community. The categories we have are:

  • Community Builder
  • Content Creator
  • Quality Assurer
  • Developer
  • Fixer
  • Ambassador
  • Rookie of the Year
  • Maverick

The criteria for these categories can be found on the Qt Champions wiki page. Also, if you think someone should be raised in several categories, or has done something that does not fit in these categories, please mention that!

We’ll keep the nominations open until the 16th December 2018 and then ask the current Qt Champions to evaluate the nominees.

Qt Champions receive hand-picked Qt Champion items and a full Qt license for a year. So nominating someone is a nice way of saying thank you!

So please go to Qt Champions for 2018 now and make your nominations for the 2018 Qt Champions!

Qt Champions

The post Looking for Qt Champions 2018 appeared first on Qt Blog.

Deprecation of Qbs

The Qt Company has been supporting three different build systems for Qt programs. For Qt users, qmake is currently the most widely used build system. CMake is a clear second and growing in popularity. The third place is Qbs, with significantly smaller adoption. When asked about their preferences, most of our customers said they plan to use either CMake or qmake in the future.

We have decided to deprecate Qbs and redirect our resources to increase support for CMake. Qbs will remain supported until the end of 2019 with the last planned release in April 2019, together with Qt Creator 4.9. Qbs is available under both commercial and open-source licenses, and we are happy to continue providing the infrastructure for further development by the Qt Project community.

To summarize the key points:

  • Qbs will continue to be supported until end of 2019
  • Last Qbs release will come out in April 2019
  • Qbs continues to work with upcoming Qt Creator 4.8 and Qt Creator 4.9
  • Qbs library and tools will be available under Qt Project for possible further development by the community
  • Support for qmake will continue unaffected
  • Support for CMake will improve
  • Longer term, we plan to switch to CMake for building Qt itself
  • CMake support in Qt Creator will be further improved

Deprecating Qbs allows us to significantly improve CMake support. We believe this change will help the growing number of our customers who prefer to use the CMake build system. Beneficial is also CMake’s wide adoption outside Qt and its active development ecosystem.

The post Deprecation of Qbs appeared first on Qt Blog.

KDAB au Capitole du Libre 2018

Du 17 au 18 novembre, KDAB sera présent au Capitole du Libre 2018 à Toulouse.

Depuis sa création en 2011, KDAB (France) soutient le monde du logiciel libre en étant Sponsor Or du Capitole du Libre.

L’événement qui a lieu à l’INP-ENSEEIHT à Toulouse accueille environ 1500 participants chaque année et l’entrée y est libre et gratuite !

Cette année encore deux de nos experts seront présents lors de ce week-end dédié au logiciel libre à travers 100 conférences et 25 ateliers.

M. Kevin Ottens animera ‘Des blobs colorés pour l’analyse de données communautaires’ et M. Franck Arrecot présentera  ‘Introduction à Qt QML et à la création de composants’

Téléchargez le programme complet de l’évènement.


In English (the event will be conducted in French):

On November 17 – 18, KDAB will be at Capitole du Libre 2018.

Since the event’s creation in 2011, KDAB (France) has supported the free software world as Gold Sponsor of Capitole du Libre.

The event that takes place at INP-ENSEEIHT in Toulouse welcomes around 1500 participants each year and admission is free!

Once again this year, two KDAB experts will be present during this weekend dedicated to free software across 100 meetings and 25 workshops.

Kevin Ottens will animate ‘Colorful Blobs for Community Data Analysis’ and Franck Arrecot will present ‘Introduction to Qt QML and to Component Creation’

Download the complete program of the event.

The post KDAB au Capitole du Libre 2018 appeared first on KDAB.

Qt Design Studio 1.0 Released

We believe that collaboration between designers and developers in an effective workflow fosters and boosts product innovation and ultimately leads to a  better user experience. That’s why I’m extremely happy to announce that Qt Design Studio 1.0 released today!

Qt Design Studio is a UI design and development environment that enables designers and developers to rapidly prototype and develop complex and scalable UIs.

Qt Design Studio is a  tool used by both designers and developers and that makes collaboration between the two a lot simpler and more streamlined: Designers can look the graphical view, while developers can look at the QML code. With this workflow, designers can have their Photoshop designs running on real devices in minutes! As an aside, I say Photoshop designs, but we are planning to support other graphic design tools in the future.

Enhanced & effective workflow with Qt Design Studio, Qt and QML

Since the tech-preview release in June, we have been working to finalize features and to bring in new ones. Let’s have a look at the features in detail:

Qt Photoshop Bridge – import your graphics design from Photoshop

  • Create re-usable components directly from Photoshop
  • Export directly to specific QML types, built-ins or custom ones
  • Export property aliases
  • New and enhanced import dialog
  • Basic merging capabilities introduced

Timeline-based animations – timeline-/keyframe-based editor that lets designers easily create pixel-perfect animations without writing a single line of code.

  • New easing-curve editor with lots of new exciting capabilities
  • Map and organize the relationship of timelines and states – create smooth transitions from state to state
  • Select multiple keyframes

Qt Live Preview – Run and preview your application or UI directly on the desktop, Android devices, and Boot2Qt devices.

  • See how your changes affect the UI live on your target device!
  • FPS counter
  • Load language translations and try them on the fly
  • Zoom in/out functionality

Lots of other features –

  • Insert a 3D Studio element and preview that on the end target device with Qt Live Preview
  • Qt Safe Renderer integration – use Safe Renderer items and map them in your UI
  • Overall enhancements in the Property panel
  • Use of states and timeline to create screen flows and transitions
  • Create artboards that can be mapped to components
  • and many more…

Head to our Qt Design Tools webpage now to learn more about Qt Design Studio and try it hands-on!

We have also created a set of how-to videos that will guide you through all the features and capabilities and show you in practice hands-on how to design and develop a UI with Qt Design Studio.

A great collection of materials and resources can also be found in our resources section.

Qt Design Studio is available today as a free tool for everyone to try out and evaluate. You will need a commercial Qt developer license to distribute your UIs created with Qt Design Studio. This means, for example, that designers or design companies can use Qt Design Studio for free, as long as the company they’re working for has the necessary commercial Qt licenses for their developers. We are also working on an open source version with a limited feature set, to be published in December. If you are interested, you can already now take a peek of the new timeline editing feature source code.

Last but not least, to learn more about Qt Design Studio and keep abreast with what’s in store in the future, make sure to watch our on-demand webinar!

The post Qt Design Studio 1.0 Released appeared first on Qt Blog.

Qt Creator 4.7.2 released

We are happy to announce the release of Qt Creator 4.7.2!

This release fixes some crashes, and the issue that antivirus programs could prevent Qt Creator from saving files on Windows.

You find more details about the fixes in our change log.

Get Qt Creator 4.7.2

The opensource version is available on the Qt download page, and you find commercially licensed packages on the Qt Account Portal. Qt Creator 4.7.2 is also available through an update in the online installer. Please post issues in our bug tracker. You can also find us on IRC on #qt-creator on chat.freenode.net, and on the Qt Creator mailing list.

The post Qt Creator 4.7.2 released appeared first on Qt Blog.

Qt 5.9.7 Released

Qt 5.9.7 is released today. As a patch release Qt 5.9.7 does not add any new functionality, but provides important bug fixes and other improvements.

Compared to Qt 5.9.6, the new Qt 5.9.7 contains almost 60 bug fixes. In total there are around 180 changes in Qt 5.9.7 compared to Qt 5.9.6. For details of the most important changes, please check the Change files of Qt 5.9.7.

Qt 5.9.7 can be updated to using the maintenance tool of the online installer. For new installations, please download latest online installer from Qt Account portal or from qt.io Download page. Offline packages are available for commercial users in the Qt Account portal and at the qt.io Download page for open-source users.

As written in previous blog posts target is still continue publishing new patch releases for Qt 5.9 series, but with slower cadence than earlier.

The post Qt 5.9.7 Released appeared first on Qt Blog.

Qt World Summit 2018 Conference App

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

In about two weeks Qt World Summit 2018 in Boston will open the doors and I just published the first release of the Conference App to the App Stores. You can download the Conference App from Google Play Store:
google-play-badge-sor Apple App Store:
The source code can be found at GitHub.The Conference App is built using QtQuickControls 2 for Android and iOS. Two years ago I developed the QtCon 2016 and the Qt World Summit 2016 Apps. The 2018 App is an update. To understand some of the concepts please take a look at the Qt Blog about 2016 Conference App and my blog post about QtCon 2016 App where I explained navigation, dynamic loading, caching and data binding.

What’s new?

Qt World Summit 2018 Conference App covers two conferences:
• QtWS2018 Boston (2018-10-29 … 30)
• QtWS2018 Berlin (2018-12-05 … 06)

Starting the app, the first conference in Boston is selected and you can easily switch between the schedules for Boston and Berlin. Later when Boston is finished, Berlin will be selected.


The schedule shows all Sessions for the selected conference and you can swipe through the days or tap on the Tab.
Hint: as of today (2018-10-12) the schedule for the training day in Berlin is missing, but will follow soon. There’s an automatic version check to see if the server has new or changed data, so you’ll always get the updates.


Tapping on a row from schedule list you get the session details:


You want to know where the room is located ? Tap on the Button to see the room details:


There’s also a list about all speakers. This list contains speakers from Boston and Berlin.


Select a Speaker to get the details:


The Sessions and Keynotes are grouped by Tracks with different colors:


Use the Drawer to navigate through all parts of the app:


The Venue Page helps you to explore the conference location. Here’s Boston:


and Berlin:


iOS 12 / iPhoneX series support

The screenshots above are all from iPhoneX, but the conference app, of course, runs on Android and iOS.

Apple requires support of iOS 12 and iPhoneX, XS, XS Max, XR with the “notch“, so it’s a good idea to prepare your app.

First step: use the full-screen area including the notch and statusbar by setting a flag:

ApplicationWindow {
flags: Qt.MaximizeUsingFullscreenGeometryHint

Now your Qt App fills the total screen and you must ensure that no data is displayed in statusbar / notch or rounded corners if the device is an iPhone X. Also on „classic“ iPhones without a notch we now cover the status bar.

Here are some screenshots where you need margins to avoid displaying data in statusbar or where the notch is. This also depends from orientation:
• Portrait
• Landscape Left
• Landscape Right

You must define the supported orientations in your info.plist:


Hint: The iPhoneX doesn’t support PortraitUpsideDown yet, but you must support this orientation because iPads need it. At first I removed it but my App was rejected by Apple.

iPhoneX Portrait


Perhaps you also need to set left and right margins because of the rounded corners.

In my Apps the root Control is a StackView with header and footer. As header and footer I have placed a ToolBar with ToolButtons and they fit into the rounded corners, so I only have to set the top and bottom margins.

iPhoneX Landscape Left


iPhoneX Landscape Right


iPhone8 Portrait


iPhone8 Landscape



HowTo manage the unsafe areas?

The margins depend on your App UI and iPhone Device.
To make it easy for you I created a C++ class UnsafeArea.cpp

In main.qml:

ApplicationWindow {
id: appWindow
// https://bugreports.qt.io/browse/QTBUG-64574
// https://stackoverflow.com/questions/46192280/detect-if-the-device-is-iphone-x
property int lastOrientation: 0
property int myOrientation: (Qt.platform.os === "ios")? Screen.orientation : 0
onMyOrientationChanged: {
if(lastOrientation === 0) {
Screen.orientationUpdateMask = Qt.LandscapeOrientation | Qt.PortraitOrientation
| Qt.InvertedLandscapeOrientation | Qt.InvertedPortraitOrientation
unsafeArea.configureDevice(Screen.height, Screen.width, Screen.devicePixelRatio)
// triggers unsafe areas and sets margins
lastOrientation = myOrientation
property int safeWidth: width - unsafeArea.unsafeLeftMargin - unsafeArea.unsafeRightMargin
property int safeHeight: height - unsafeArea.unsafeTopMargin - unsafeArea.unsafeBottomMargin

Starting the App the Screen.orientation changes the first time and we use this as a trigger to set Screen.orientationUpdateMask and to configure the device.

Different iPhone models are detected by screen pixel size – see the details here.

If orientation changes the margins will be set automatically, per ex:

void UnsafeArea::orientationChanged(int orientation)
if(orientation == 1) {
} else if(orientation == 2) {
} else if(orientation == 4) {
} else if(orientation == 8) {
} else {

void UnsafeArea::portrait()
switch (mMyDevice) {
case MyDevice::IPHONE_X_XS:
case MyDevice::IPHONE_XSMAX:
case MyDevice::IPHONE_XR:
case MyDevice::IPHONE_5_5S_5C:
case MyDevice::IPHONE_6_6S_7_8:

To get the margins from UnsafeArea.cpp:

Q_PROPERTY(int unsafeTopMargin READ unsafeTopMargin ...
Q_PROPERTY(int unsafeBottomMargin READ unsafeBottomMargin ...
Q_PROPERTY(int unsafeLeftMargin READ unsafeLeftMargin ...
Q_PROPERTY(int unsafeRightMargin READ unsafeRightMargin …

Now in QML, you can use these margins to adjust your UI. In my App the root StackView has a header and footer, so I had to adjust them. Per ex the header:

ToolBar {
id: myTitleBar
topPadding: unsafeArea.unsafeTopMargin? unsafeArea.unsafeTopMargin : undefined

In my Pages I had to watch that left and right margins will be set correct:

Page {
StackView {
id: navPane
anchors.fill: parent
anchors.leftMargin: unsafeArea.unsafeLeftMargin
anchors.rightMargin: unsafeArea.unsafeRightMargin

There are some use cases where I’m calculating sizes or positions depending on the width and height of ApplicationWindow. Now I have to subtract the top, bottom, left and right margins from unsafe areas.

ApplicationWindow {
property int safeWidth: width - unsafeArea.unsafeLeftMargin - unsafeArea.unsafeRightMargin
property int safeHeight: height - unsafeArea.unsafeTopMargin - unsafeArea.unsafeBottomMargin

What about Android Devices with notch?

Since Android Pie there are also some devices with a notch. I’ll add support for Android later.


The QtWS2018 Conference App is an update of my old 2016 Conference App. In the meantime, many Controls are new or got new functionality. I haven’t found the time to update all of this, but hopefully before QtWS2018 Berlin starts. Remember: I’m doing all of this in my rare spare time.

See you

If you want to discuss the App or mobile business app development with QtQuickControls2 you can meet me in Boston or Berlin – I’ll attend both conferences.

If you haven’t already done: take a look at my blog series Qt for Mobile Business Apps.

The post Qt World Summit 2018 Conference App appeared first on Qt Blog.

New in Qt 5.11: improvements to the model/view APIs (part 2)

In the last episode of this series we discussed QAbstractItemModel::checkIndex().

QAbstractItemModel::checkIndex() is a function added in Qt 5.11 that allows developers of model classes to perform some validity checks on the QModelIndex objects passed to the model; specifically, on the indices passed to the APIs that model classes need to implement (rowCount(), columnCount(), data, setData(), etc.).

These validity checks can be very useful when developing (and debugging) the model itself, or when using a complicated stack of models and proxy models.

However, by its nature, checkIndex() will check just the one index passed to it. It is unable to perform consistency checks on the model “as a whole”. For instance, for a given index, a model’s reimplementation of hasChildren() must be consistent with the values returned by rowCount() and columnCount().

Enter QAbstractItemModelTester

QAbstractItemModelTester is a new class in Qt 5.11 which helps to test item models. It complements checkIndex() by checking the consistency of the entire model from the point of view of a user of the model (like a view).

(Technically speaking, it’s not really new: Qt has had a private class called ModelTest amongst its own autotests for years; ModelTest‘s usecase is the same as QAbstractItemModelTester. For Qt 5.11 I’ve took ModelTest, cleaned it up, renamed it to QAbstractItemModelTester and added it as public API in the QtTest module.)

QAbstractItemModelTester is simple and immediate to use: just create an instance, and pass to its constructor the model that needs to be tested, like this:

QAbstractItemModelTester *tester = new QAbstractItemModelTester(modelToTest);
// keep the tester object around; it will run a series of tests on modelToTest

QAbstractItemModelTester will then automatically perform a series of non-destructive checks on the model. These checks are aimed at verifying the model’s overall consistency; they will verify that the (many) function of the QAbstractItemModel API are always coherent, and will not confuse anyone using the model (like a view, or a proxy model).

Furthermore, QAbstractItemModelTester will also listen to the signals emitted by the model to test; an emission triggers further validation checks, for instance emitting that a row has been added to the model will make tester verify that the row count has been increased by exactly 1.


As an example, let’s consider this very simple model class (a list model of strings):

class StringListModel : public QAbstractListModel {
    using QAbstractListModel::QAbstractListModel;

    int rowCount(const QModelIndex &parent) const override {
        if (parent.isValid())
            return 0;
        return m_strings.size();

    QVariant data(const QModelIndex &index, int role) const override {
        Q_ASSERT(checkIndex(index, QAbstractItemModel::CheckIndexOption::IndexIsValid));
        if (role != Qt::DisplayRole)
            return {};
        return m_strings[index.row()];

    // appends the string at the end of the model
    void appendString(const QString &string) {
        beginInsertRows(QModelIndex(), m_strings.size(), m_strings.size() + 1);

    QStringList m_strings;

The implementation of the model is straightforward: since it’s a list model, only rowCount() and data() need to be implemented. Our model also has a third function (appendString()) that allows the application code to insert a new string into the model, specifically, at the very end.

Let’s focus on this very last function. When inserting new rows into a model, we are supposed to notify the views about the change. QAbstractItemModel’s documentation tells us to use a “transactional” approach: we need to call beginInsertRows() before inserting, perform the insertion, then call endInsertRows().

The parameters to beginInsertRows() describe how many new rows are being inserted, and at which position (the documentation discusses all the details); in our case, we are adding exactly one row at the very end of the model, so we pass m_strings.size() as the position at which the new row will appear.

The third parameter is however wrong: it’s basically stating that we are going to add two rows at the end of the model, while we’re actually adding only one. If we read the documentation carefully, we notice that the parameter shall indicate the index of the last row being added; since we’re adding only one, the index of the last row being added is the same as the first row being added. In order words: the second and third parameter of beginInsertRows() should be identical, like this:

        // correct call: adds 1 row, at position m_strings.size()
        beginInsertRows(QModelIndex(), m_strings.size(), m_strings.size());

These sort of mistakes (in the end, an off-by-one error) can cause lots of troubles: for instance, persistent model indexes start pointing to the wrong data, proxy models get corrupted, and so on.

If we use our model into a QAbstractItemModelTester, we get a notification that there is something wrong going on. For instance, given this setup:

    auto model = new StringListModel;
    auto tester = new QAbstractItemModelTester(model, 

Sometime later, when appendString() is called, QAbstractItemModelTester will detect the mismatch between the rows we are promising we are adding to the model, and the ones we are actually adding to the model. Since the tester object is set to Warning mode it will print a warning on the console, like this:

FAIL! Compared values are not the same:
   Actual (model->rowCount(parent)) 1
   Expected (c.oldSize + (end - start + 1)) 2

We can then use ordinary debugging tools (e.g. a debugger with a breakpoint) to debug what condition caused this warning. We will then notice that the call stack leading to the warning starts in our appendString() function, so we need to double check it and figure out what’s going on in there.

Lastly, note the calls to checkIndex() in the model’s functions that implement the QAbstractListModel API (by overriding rowCount() and data()). QAbstractItemModelTester and checkIndex are meant to complement each other, as the former tests the entire model, while the latter is used to validate the model indexes passed to the various functions.

Reporting failures

In case some of the checks fail, QAbstractItemModelTester has three different ways of reporting the failure to the developer, selectable via an argument to the constructor:

  • By default, QAbstractItemModelTester uses the QtTest failure report mode: failures are reported through the QtTest’s logging mechanisms. This report mode is suitable if we are using QAbstractItemModelTester in a test driven by the QtTest framework, for instance when building unit tests for our model class; a problem in our model will result in the current test function being marked as failing.
  • QAbstractItemModelTester is also usable outside unit tests driven by QtTest. By specifying the Warning failure mode, QAbstractItemModelTester will print a warning statement in the qt.modeltest logging category.
  • Finally, the Fatal failure mode causes the application to crash immediately. In this mode, if a check fails, QAbstractItemModelTester is going to call qFatal() passing a string with a textual description of the error.

No matter which failure mode is set, QAbstractItemModelTester will print debug information about our model in the aforementioned qt.modeltest logging category, showing what kind of changes were detected by the tester class and what sorts of checks are being run. Sometimes this can be useful in order to track down bugs.

Note that this debug output needs to be explicitly enabled by the developer, for instance by setting the QT_LOGGING_RULES environment variable to contain the string qt.modeltest.debug=true. (For more information on Qt’s logging categories, see here).


It is important to note that QAbstractItemModelTester will never perform destructive tests on a model (set new data, insert/remove rows and columns, and so on). This allows developers to safely use the tester in all conditions, including having it enabled in a full build of the application. This way models can be tested in real-world conditions, using actual data, as well as in long-running scenarios (which maybe are required to trigger some bug).

On the other hand, in order to thoroughly test a custom model, we may need to write checks for destructive changes. Since only the developer knows the exact behaviour of a model that undergoes a modification, the developer is supposed to write dedicated unit tests, thus complementing the tests done by QAbstractItemModelTester.

Finally: as I wrote in the last blog post, I believe that the model/view APIs in Qt have a narrow contract: one should never attempt to pass invalid data to a model (e.g. a model index out of range). QAbstractItemModelTester honours this, and will never attempt any illegal operation on a model. If for some reason you need to give your model a wide contract and want to test that contract, further tests (outside QAbstractItemModelTester) are needed.

That’s it for now for now, but stay tuned for more contributions to Qt!

The post New in Qt 5.11: improvements to the model/view APIs (part 2) appeared first on KDAB.

Measuring The Impact of Qt on Your Business

Today, I wanted to talk to you about a recently conducted Total Economic Study for commercial customers of Qt by Forrester Consulting. Please find the report here.


In many ways, Qt has been ahead of its time. Its ability to work on basically anything now truly shines as the Internet of Things (or “Internet of Thinking”, as we move into the future) matures. And with the number of devices developed still exponentially outgrowing the number of developers, tools like Qt become a necessity to keep up with the market.

We all ask ourselves, as we should: “Are we doing the right thing?”

A lot of our customers have done so before they adopted Qt. Understandably so: You expect your software to be around for years, even decades, and committing to a development framework is a high-risk decision that will directly impact your organization, its bottom line, and competitiveness for years to come.

The questions will take various shapes as different considerations become relevant throughout the project life-cycle:

Short-term considerations: “What will my return on investment be?” “Will it help me meet the market requirements and customer expectations?” “Does our workforce have the right skillset to adopt the tool into a unified development process?”

Mid-term considerations: “How will a framework impact development and (for embedded devices) hardware cost?” “Will it help me go to market faster?” “What other competitive advantages can it incur?”

Long-term considerations: “Will the framework still be supported in ten years?” Does it help me minimize the maintenance of toolchains and the associated costs?” “What are the costs if I want to expand my software to other platforms in the future?”

At the Qt Company, we too constantly ask ourselves: “Are we doing the right thing?” And because we all have some degree of bias towards what is ours, we have to look outside for answers.


Our annual customer survey, for example, shows encouraging results: In 2017, Qt has met or exceeded 95.3% of our customer’s ROI expectations and made 78.2% of developers more productive. That is fantastic, but I was curious to see how someone from the outside would quantify the value of our product.

Forrester conducted a Total Economic Impact study to examine the potential return on investment businesses may realize with Qt and evaluate its potential financial impact on organizations.

To do that, Forrester interviewed four commercial Qt customers and used the data to construct a composite organization. The key findings on how Qt affected the organization’s business exceeded even the expectations set by our own survey:

  •  The payback period for Qt’s licensing and operational costs was three months
  • The ROI after three years was 289%.
  • The net present value measured over a three-year period was $422’833

Further findings from the interviews that apply to any organization were:

  • Customers saved (on average) 30% of their software development costs by using Qt.
  • Customers could reduce hardware costs by 10% coming from a native and up to 80% from an HTML toolchain.
  • Device innovations and improvements released to market sooner because the development process was simpler and faster.
  • The fact that Qt is mature, stable and well supported gave customers a sense of confidence for the future.

Forrester was so kind to share with us their algorithm used to estimate the ROI for Qt embedded customers. Please feel free to try it to find out how Qt would affect your company.

While these results reassure us that we’re doing the right thing in enabling you to create better products faster and at a lower cost, we do not want to sit on our laurels. Instead, we want to take this feedback as encouragement to keep questioning and improving ourselves.

So, to all of you that brought us this far by challenging us to achieve greater heights every day, the customers and the competitors, the developers and the business people, the thinkers and the dreamers.

Thank you!

Juha Varelius, CEO, The Qt Company


The post Measuring The Impact of Qt on Your Business appeared first on Qt Blog.

Modern Qt Development: The Top 10 Tools You Should Be Using

by Matthias Kalle Dalheimer (Qt Blog)

Why is using the right tool for the job so important? Efficiency and results are two reasons that immediately spring to mind. You don’t see construction workers using shoes to drive in nails – so why as software developers do we so often make do with manual solutions to find bugs or optimize code? It’s certainly less efficient and much more frustrating, and the final results can be less than ideal.

It always takes time to learn a new tool – so how do you know where you should invest your time? We at KDAB would like to share our favourite Qt development tools that we think are worth the effort. We regularly rely on these tools to help us locate and fix troublesome bugs and solve difficult optimization challenges. If you live at the cutting edge of Qt development you may be familiar with many of these, but we know there’ll be something new for you regardless of your level of expertise.

GammaRayintrospection tool that adds Qt-awareness to the debugger  

If you’ve been frustrated by debugging through endless Qt structure internals, you’ll definitely want to give this a try. GammaRay understands most of the core Qt components from a Qt perspective – QtQuick scene graphs, model/view structures, QTextDocuments, signal/slot activations, focus handling, GPU textures, QWidgets, state machines, and more – letting you observe and edit values at run-time in a natural way. You can debug applications from launch or attach to running apps (both local and remote).

Clazycompiler plug-in that understands Qt semantics

This is something that needs to be part of every Qt developer’s bag of tricks. By adding clazy to clang, you’ll get compile-time warnings for Qt best practices – unneeded memory allocations, misused APIs, or inefficient constructs. Clazy is a great way to improve your Qt code and best of all, it can provide automatic refactoring fixes for some of the errors it finds – no coding required!

Modern C++source code that uses C++11/14/17 improvements

Although C++11 and C++14 have been around for a while now, there are many old coding habits that die hard. Many developers don’t take advantage of newer C++ constructs that are more efficient, understandable, and maintainable. The thing is you don’t need to be a C++ standards expert to make small changes that can significantly help your code. We’ve got a few of the more important highlights covered in a paper below – or you can attend a training class or two for the real low-down.

Clang Tidycompiler toolto help modernize your C++

This is the lazy person’s way to modernize C++. Another clang-based tool, Clang Tidy points out older C++ idioms that could use updating. It flags where these should be replaced with new C++11 or C++14 improvements, and in many cases can do the refactoring automatically. That’s productivity for you!

HotSpottool to visualize your app’s CPU performance

When it comes to optimizing, nothing beats a profiler – but reading raw perf logs is a punishment that should only be reserved for people who believe zip files are a proper form of source control. HotSpot reads Linux perf logs and lets you see multiple different views (callers, timeline, top-down, bottom-up) to help you easily understand where you’re burning up your time.

apitraceset of tools to debug your graphics APIs and improve their performance

If you’re writing an app with a GUI, profiling doesn’t stop at your C++ code. You need a way to see the calls you’re making to OpenGL, Direct3D, or DirectDraw, view the contents of those calls in a graphical interpretation, and profile their performance. That’s exactly what apitrace does. It can also replay a trace file, allowing you to compare and benchmark performance once you’ve seen where to make improvements.

Kernel/System Profilertools for visualizing your operating system’s performance

Sometimes performance problems aren’t found in your app – they’re in multiple-process interactions, hidden in driver stacks, or a result of how you’re calling the operating system. For these kinds of really low-level debugging, you’ve got to have a system-profiling tool. It can feel like swatting a fly with a bazooka, but a system profiler is an incredibly invaluable tool that can find problems that nothing else will.

Heaptracktooling to watch your app’s memory usage

Sometimes optimization isn’t about speed – it’s about memory. If you’re trying to profile yourapplication’s memory usage, you’ll want to check this out. By showing your application’s peak memory usage, memory leaking functions, biggest allocators, and most temporary allocations, you’ll be able to really narrow down where your app’s memory is going and how to keep it on a diet.

Continuous Integration (CI)build systems for agile/XP development

Continuous integration fits hand-in-hand with unit testing as a methodology that can bring very real improvements to your software quality – whether you’re using agile development or not. Don’t bother creating your CI build system from scratch when there are a lot of great tools that can give you a leg up on delivering quality products.

Qt Creatorthe Qt IDE

Perhaps you think it’s cheating to include Qt Creator in this list since it’s already installed on every Qt developer’s desktop. Yes, but did you know you can find slowspots in your Qt Quickcode through the built-in QML profiler? How about hitting Alt+Enter to get a list of all the refactoring options at the cursor location?What about other handykey sequences to find symbol references, do a git diff, or record a macro, along with many other super helpful navigation and editing aides? Shortcuts that you might use ten times a day if you only knew they were there. Don’t be a slave to your mouse – print out our handy reference card and pin it up on your cube wall.

Those are our top ten tools for improving your Qt development tool chest. Don’t forget there are also things that can’t be automated but for which there are courses and customized training – such as effective code reviews or best coding practices.

Is there anything else that you’ve found to be invaluable that you want to share? Please leave a suggestion in the comments!

The post Modern Qt Development: The Top 10 Tools You Should Be Using appeared first on Qt Blog.

Clazy 1.4 released

Clazy 1.4 has been released and brings 10 new checks.

Clazy is a clang compiler plugin which emits warnings related to Qt best practices. We’ll be showing Clazy at Qt World Summit in Boston, Oct 29-30, where we are a main Sponsor.

You can read more about it in our previous blog posts:

Today I’ll go through all 10 new warnings, one by one. For other changes, check the complete 1.4 Changelog. So let’s start. I’ve ordered them according to my personal preference, starting with the ones that have helped me uncover the most bugs and finishing with some exotic ones which you’ll rarely need.

1. skipped-base-method

Warns when calling a method from the grand-base class instead of the direct base class one.


class MyFrame : public QFrame
    bool event(QEvent *ev) override
        // warning: Maybe you meant to call QFrame::event() instead [-Wclazy-skipped-base-method]
        return QWidget::event(ev); 

The motivation came after hitting bugs when overriding QObject::event() and QObject::eventFilter(). I would suggest always using this check and annotating your legit cases with // clazy:exclude=skipped-base-method, to make your intention clear. The same way you would comment your fallthroughs in switch statements.

This check might get removed in the future, as in the end it’s not specific to Qt and clang-tidy recently got a similar feature.

2. wrong-qevent-cast

Warns when a QEvent is cast to the wrong derived class via static_cast.


switch (ev->type()) {
    case QEvent::MouseMove:
        auto e = static_cast<QKeyEvent*>(ev);

Only casts inside switch statements are verified.

3. qhash-with-char-pointer-key

Finds cases of QHash<const char *, T>. It’s error-prone as the key is just compared by the address of the string literal, and not the value itself.

This check is disabled by default as there are valid use cases. But again, I would suggest always using it and adding a // clazy:exclude= comment.

4. fully-qualified-moc-types

Warns when a signal, slot or invokable declaration is not using fully-qualified type names, which will break old-style connects and interaction with QML.

Also warns if a Q_PROPERTY of type gadget is not fully-qualified (Enums and QObjects in Q_PROPERTY don’t need to be fully qualified).


namespace MyNameSpace {

    struct MyType { (...) };

    class MyObject : public QObject
        Q_PROPERTY(MyGadget myprop READ myprop); // Wrong, needs namespace
        void mySignal(MyType); // Wrong
        void mySignal(MyNameSpace::MyType); // OK

Beware that fixing these type names might break user code if they are connecting to them via old-style connects, since the users might have worked around your bug and not included the namespace in their connect statement.

5. connect-by-name

Warns when auto-connection slots are used. They’re also known as “connect by name“, an old and unpopular feature which isn’t recommended. Consult the official documentation for more information.

These types of connections are very brittle, as a simple object rename would break your code. In Qt 5 the pointer-to-member-function connect syntax is recommended as it catches errors at compile time.

6. empty-qstringliteral

Suggests to use an empty QString instead of an empty QStringLiteral. The later causes unneeded code bloat.

You should use QString() instead of QStringLiteral() and QString("") instead of QStringLiteral("").

7. qt-keywords (with fixit)

Warns when using Qt keywords such as emit, slots, signals or foreach.

This check is disabled by default. Using the above Qt keywords is fine unless you’re using 3rdparty headers that also define them, in which case you’ll want to use Q_EMIT, Q_SLOTS, Q_SIGNALS or Q_FOREACH instead.

This check is mainly useful due to its fixit to automatically convert the keywords to their Q_ variants. Once you’ve converted all usages, then simply enforce them via CONFIG += no_keywords (qmake) or ADD_DEFINITIONS(-DQT_NO_KEYWORDS) (CMake).

8. raw-environment-function

Warns when putenv() or qputenv() are being used and suggests the Qt thread-safe equivalents instead. This check is disabled by default and should be enabled manually if thread-safety is important for you.

9. qstring-varargs

This implements the equivalent of -Wnon-pod-varargs but only for QString.

This check is only useful in cases where you don’t want to enable -Wnon-pod-varargs. For example on projects with thousands of benign warnings (like with MFC’s CString), where you might only want to fix the QString cases.

10. static-pmf

Warns when storing a pointer to a QObject member function and passing it to a connect statement. Passing such variable to a connect() is known to fail at runtime when using MingW.

You can check if you’re affected by this problem with the following snippet:

static auto pmf = &QObject::destroyed;
if (pmf == &QObject::destroyed) // Should be false for MingW

Conclusion and thoughts for version 1.5

Clazy has matured and it’s getting increasingly difficult to come up with new ideas for checks. For version 1.5 I won’t be focusing in writing new warnings, but instead figuring out how to organize the existing ones.

This project has come a long way, there’s now 77 checks and I feel the current classification by false-positive probability (levels 0, 1, 2, 3) is not scaling anymore. I will try to organize them by categories (bug, performance, readability, containers, etc), which would be orthogonal to levels and hopefully also answer the following questions:

  • What’s the absolute sub-set of checks that every project should use ?
  • Which ones should abort the build if triggered (-Werror style) ?
  • How to make clazy useful in CI without getting in the way with annoying false-positives ?
  • How to let the user configure all this in an easy way ?

But of course, if you know of any interesting check that wouldn’t cost me many days of work please file a suggestion or catch me at #kde-clazy (freenode) and it might make it to the next release.

The post Clazy 1.4 released appeared first on KDAB.

Qt Creator 4.8 Beta released

We are happy to announce the release of Qt Creator 4.8 Beta!


Generic Programming Language Support

In Qt Creator 4.8 we’ll introduce experimental support for the language server protocol. For many programming languages there is a “language server” available, which provides IDEs with a whole lot of information about the code, as long as they support communicating via the protocol.

This means that by providing a client for the language server protocol, Qt Creator gets (some) support for many programming languages “for free”. Currently Qt Creator supports code completion, highlighting of the symbol under cursor, and jumping to the symbol definition, as well as integrates diagnostics from the language server. Highlighting and indentation are still provided by our generic highlighter, since they are not provided via the language server protocol.

To use a language server, you first need to enable the LanguageClient plugin in Help > About Plugins (Qt Creator > About Plugins on macOS). Then add the server in Tools > Options > Language Client, choosing a MIME type (glob patterns are in the works), server executable and any required command line arguments. The server is automatically started – just open a file of the corresponding type and start hacking :).

Note that the client is mostly tested with Python. There will most probably be one or the other issue when you try your most favorite language. Also, we currently do not support language servers that require special handling. If you find issues, we are happy to receive bug reports, preferably including Qt Creator console output with the environment variable  QT_LOGGING_RULES=qtc.languageclient.*=true set.

C++ Support

On the C++ side we added some experimental features.

Compilation Database Projects

Open a compilation database as a project purely for editing and navigating code. A compilation database is basically a list of files and the compiler flags that are used to compile them. Some build systems and tools are able to generate such databases for use in other tools. In Qt Creator it feeds the code model with the necessary information for correctly parsing the code. Enable the plugin CompilationDatabaseProjectManager to try it.

Clang Format Based Indentation

Does auto-indentation via LibFormat which is the backend used by Clang Format. Enable the plugin ClangFormat to try it.

Cppcheck Diagnostics

Integrates diagnostics generated by the tool Cppcheck into the editor. Enable the plugin Cppcheck to try it.

Aside from many other fixes, the Clang code model can now jump to the symbol represented by the auto keyword. It also allows generation of a compilation database from the information that the code model has via Build > Generate Compilation Database.


We added support for simultaneously running debuggers on one or more executables. When multiple debuggers are currently running, you can switch between the instances with a new drop-down menu in the debugger tool bar in Debug mode.

There have been many more improvements and fixes in Qt Creator 4.8, which you can read about in more detail in our change log.

Get Qt Creator 4.8 Beta

The opensource version is available on the Qt download page, and you find commercially licensed packages on the Qt Account Portal. Qt Creator 4.8 Beta is also available under Preview > Qt Creator 4.8.0-beta1 in the online installer. Please post issues in our bug tracker. You can also find us on IRC on #qt-creator on chat.freenode.net, and on the Qt Creator mailing list.

The post Qt Creator 4.8 Beta released appeared first on Qt Blog.

Introducing the Distance Field Generator

by Eskil Abrahamsen Blomfeldt (Qt Blog)

At least from the perspective of rendering, text is often the most complex part of a traditional two-dimensional user interface. In such an interface, the two main components are rectangular images and text. The rectangular images are often quite static, and can be represented by two triangles and four indexes into a texture atlas that is uploaded to graphics memory once and then retained. This is something that has low complexity and which the graphics hardware has been optimized to handle quickly.

Text starts as a series of indexes into an international database of writing systems (Unicode). It is then, based on some selection algorithm, combined with one or more fonts, which is in principle a collection of shapes and some lookup tables and executable programs that convert said indexes into shapes and relative positions. These shapes, basically filled paths made out of bezier curves, then have to be rasterized at a specified size, and this can range from simple and neat outlines to complex ones with lots of detail. (By rasterization, I mean finding out how much of each target pixel, or subpixel in some cases, is covered by the shape.)

The letter Q

Objectively the most beautiful character in the Latin alphabet. Here represented by a rasterized image of three channels, respectively giving the coverage of the red, green and blue target subpixels. Scaled by 400% to make the pixels visible.

All combined, it is a heavy process. But luckily, instead of redoing every step for every string, we can often cache intermediate results and reuse them later.

For instance, it is possible to rasterize the glyphs the first time they are used, keep this in memory, and then at each subsequent use, render these glyphs the same way images are rendered as described above: By putting the rasterized glyphs in a texture atlas and representing the glyphs by two triangles and indexes into this atlas. In fact, when the Text.NativeRendering render type is in use in Qt Quick, this is precisely what happens. In this case, we will ask the underlying font system (CoreText on macOS, GDI/DirectWrite on Windows and Freetype on Linux) to rasterize the glyphs at a specific size, and then we will upload these to a texture atlas which can later be referenced by the triangles we put on the screen.

Texture glyph cache

Contents of texture atlas in a typical Qt application.

There are some limitations of this approach however: Since the font size has to be known before the glyphs are rasterized, we may end up rasterizing and caching the same glyphs multiple times if the text in the UI comes in many different sizes. For some UIs that can be too heavy both for frame rate and memory consumption. Animations on the font size, for instance, can cause us to rasterize the shapes again for every frame. This rasterization is also done on the CPU, which means we are not using the resources of the device to its full potential when preparing the glyphs.

Additionally, transformations on the NativeRendering text will give pixelation artifacts, since they will be applied to the pre-rasterized image of the glyph, not its actual mathematical shape.

So what is the alternative?

For a more flexible approach, we want to actually do the rasterization on the GPU, while rendering our frame. If we can somehow get the shapes into the graphics memory and rasterize them quickly using a fragment shader, we free up CPU resources and allow both transformations and size changes without any additional penalty on performance.

There are several approaches to this problem. The way is is done in Qt is by using so-called distance fields. Instead of storing the rasterized glyphs in texture memory, we store a representation of the shapes in a texture atlas where each texel contains the distance to the nearest obstacle rather than the coverage.

Distance field for letter Q in Deja Vu Sans

A distance field of the same Q, as an 8-bit map where each value is set to the distance to the nearest point on the outline of the glyph

Once these distance fields are created and uploaded to texture memory, we can render glyphs at any font size and scale quickly on the GPU. But the process of converting the shapes from the fonts into distance field is still a bottle neck for startup time, and that in particular is what this blog is about.

So what is the problem?

Creating the distance fields is CPU-bound, and – especially on lower-end hardware – it may be very costly. By setting the QT_LOGGING_RULES environment variable to “qt.scenegraph.time.glyph=true” we can gain some insight into what that cost is. Lets for instance say that we run an example that displays 50 unique Latin characters with the Deja Vu Sans font (the simple and neat outlines further up). With the logging turned on, and on an NXP i.MX6 we have for testing in our QA lab, we get the following output:

qt.scenegraph.time.glyph: distancefield: 50 glyphs prepared in 25ms, rendering=19, upload=6

From this output we can read that generating the necessary assets for these 50 glyphs took 19 ms, over one whole frame, whereas uploading the data to the graphics memory took 6 ms. It is the 19 ms for converting into distance fields that we will be able to reduce. These 19 ms may not seem like a lot, but it will cause the rendering to skip a frame at the point where it happens. If the 50 glyphs are displayed at startup, then those 25 ms may not be as noticeable, but if it is done during an animation, it would be something a user could notice. It is worth mentioning again, though, that it is a one-time cost as long as the font remains in use.

Running the same for the HVD Peace font (linked as the complex font above), we get the following output:

qt.scenegraph.time.glyph: distancefield: 50 glyphs prepared in 1016ms, rendering=1010, upload=6

In this case, we can see that rendering the distance fields takes a full second, due to the high complexity of the outlines in use.

Another use case where we may see high costs of generating distance fields is if the number of unique glyphs is very high. So let us test an arbitrary, auto-generated “lorem ipsum” text in Chinese with 592 distinct characters:

qt.scenegraph.time.glyph: distancefield: 592 glyphs prepared in 1167ms, rendering=1107, upload=60

Again, we see that generating the distance fields takes over one second. In this case, the upload also takes a bit longer, since there is more data to be uploaded into graphics memory. There is not much to be done about that though, other than making sure it is done at startup time and not while the user is watching a smooth animation. As mentioned, though, I will focus on the rendering part in this blog.

So what is the solution?

In Qt 5.12, we will release a tool to help you improve on this for your application. It is called “Qt Distance Field Generator” and you can already find the documentation in our documentation snapshot.

The way this works is that it allows you to pregenerate the distance fields for either a selection of the glyphs in a font or all of them. Then you can append these distance fields as a new font table at the end of the font file. Since this custom font table follows SFNT conventions, the font will still be usable as a normal TrueType or OpenType file (SFNT mandates that unsupported font tables are ignored).

So the font can be used as normal and is still compatible with e.g. Qt Widgets and Text.NativeRendering, where the rasterization will still go through the system.

When the font is used in Qt Quick with Text.QtRendering, however, the special font table will be detected, and its contents will be uploaded directly to graphics memory. The cache will therefore be prepopulated with the glyphs you have selected, and the application will only have to create distance fields at runtime if they are missing from this set.

The result of this can be impressive. I repeated the experiments, but with fonts where I had pregenerated distance fields for all the glyphs that were used in the example.

First example, simple and neat “Deja Vu Sans” font, 50 latin characters:

qt.scenegraph.time.glyph: distancefield: 50 pre-generated glyphs loaded in 11ms

Second example, complex “HVD Peace” font, 50 latin characters:

qt.scenegraph.time.glyph: distancefield: 50 pre-generated glyphs loaded in 4ms

Third example, 592 Chinese characters:

qt.scenegraph.time.glyph: distancefield: 592 pre-generated glyphs loaded in 42ms

Comparison of results on i.MX6

As we can see, there is a great improvement when a lot of time is spent on creating the distance fields. In the case of the complex font, we got from 1016 ms to 4 ms. When more data is uploaded, that will still take time, but in the case of the Chinese text, the upload was actually faster than when the distance fields were created on the fly. This is most likely a pure coincidence, however, caused by the order of the glyphs in the cache causing slightly different layouts and sizes.

Another peculiar thing we can see is that the complex font is faster to load than the simple one. This is simply because the glyphs in that font are square and compact, so there is not a lot of unused space in the cache. Therefore the texture atlas is a little bit smaller than for the simpler font. The complexity of the outlines does not affect the loading time of the atlas of course.

Running the same tests on my Windows Desktop workstation, we see that there is not as much overhead for generating the distance fields, but there is still some performance gain to be seen in some cases.

Comparison of results on Windows Desktop

For 50 Latin glyphs with Deja Vu Sans, both tests clocked in at 3 ms, which was mainly spent uploading the data. For HVD Peace, however, generating the distance fields took 131 ms (versus 1 ms for just the upload) and for the Chinese text it took 146 ms (vs 11)

Hopefully this can help some of you get even better performance out of your Qt devices and applications. The feature is already available in the Qt 5.12 beta, so download the package and take it for a test drive right away.

The post Introducing the Distance Field Generator appeared first on Qt Blog.

QML Debugging in Visual Studio

The next release of the Qt Visual Studio Tools, v2.3.0, will allow debugging of QML applications in Visual Studio. It will be possible to set breakpoints in QML files and step through the execution of QML code. While in break mode, it will be possible to watch variables and change their values, as well as evaluate arbitrary expressions. The QML debug session will run concurrently to the C++ debug session, so it will be possible to set breakpoints and watch variables in both C++ and QML during the same debug run of the application.

This new debugging feature of the Qt VS Tools integrates with the QML debugging infrastructure, a part of the Qt QML module which provides services for debugging, inspecting, and profiling applications via a TCP port. To extend the Visual Studio debugger with features of the QML debugging infrastructure, a Visual Studio QML debug engine is provided. This debug engine consists, for the most part, of implementations of interfaces from the Active Debugging 7 (AD7) extensibility framework for the Visual Studio debugger.

If a Qt project contains any QML resource files, starting a debug session (e.g. by pressing F5), besides launching the native application, now also connects to the QML debugging infrastructure of that application. This can be seen in the Processes window of the Visual Studio debugger: two processes are listed, a native process that corresponds to the actual physical process created for the C++ debugging session, and a QML process, which does not correspond to any physical process that is running on the machine, but rather represents the connection to the QML debugging runtime within the native process.


Since both a native process and a QML process are present, it is possible to request breakpoints both in C++ or QML code. The Visual Studio debugger will forward requests to the appropriate debug engine. As usual, a filled circular breakpoint marker in QML code indicates a valid breakpoint; this means that a breakpoint request for that file position has been sent to, and confirmed by the QML runtime.


When a breakpoint is hit, Visual Studio will show the current state of the call stack. Unlike other scenarios of debugging applications that use different languages (e.g. .NET + Native debugging), the QML debug engine does not provide true mixed mode debugging. It runs concurrently with the native debug engine and, from the point of view of the Visual Studio debugger, it is not related to the native process. This means that, even though it is possible to debug both C++ and QML in the same debugging session, the stack that is shown when a QML breakpoint is hit will only include QML function calls — the C++ context of those calls will not be available.


As in the case of native debugging, while in break mode, it is possible to view and modify the values of local variables, in the context of the currently active call stack frame, as well as create watches for any variable or expression. The Immediate window is also available for evaluation of any expression in the context of the current stack frame.


Moving the mouse over a QML expression pops up an instant watch window (or “DataTip”). The value of that expression in the current context is displayed and can also be modified.


QML debugging is enabled by default for any Qt QML application. It is possible to disable QML debugging, and revert to native-only debugging, by opening the Qt project settings dialog and setting the “QML Debug” option to “Disable”. In this dialog, it is also possible to change the port that is used by the QML debugging runtime.


As mentioned, the QML debugging feature of the Qt VS Tools will be available in the next version, scheduled for release in the Visual Studio Marketplace later this year. A preview version will shortly be available for download on the Qt website; we’ll post a quick update here when it is available.

The post QML Debugging in Visual Studio appeared first on Qt Blog.

Extending the Performance Analysis Toolset

The Linux Foundation holds its Open Source Summit + Embedded Linux Conference Europe in Edinburgh, October 22 – 24, 2018

In spite of the clumsy name, this is an event you won’t want to miss!

KDAB’s Christoph Sterz will be presenting a talk on Tuesday, October 23 • 15:50 – 16:30:

Extending the Performance Analysis Toolset 

Finding and analyzing performance issues on embedded devices can be a tiresome search. Nowadays, modern sampling and tracing technologies are built into the Linux kernel to address this, in the form of perf and LTTng respectively. Still, the vast amounts of data recorded are difficult to handle on the limited embedded devices themselves.

In his talk, Christoph will present Hotspot, an open-source performance analysis tool and how to optimize sophisticated tracepoint analysis as well as outline KDAB’s plans in instrumenting Qt for the LTTng tracing ecosystem.

Read more…

Open Source Summit + Embedded Linux Conference Europe (OSSEU) is the technical conference for professional open source and the leading conference for developers, architects and other technologists – as well as open source community and industry leaders.

15% Attendee Discount Offer

Sign up here and get a 15% discount, by using the following code: SPKSHARE15


The post Extending the Performance Analysis Toolset appeared first on KDAB.

Qt 5.12 LTS Beta Released

I am pleased to announce that we released the first beta of Qt 5.12 LTS today. Qt 5.12 LTS is expected to be a solid development base and to receive multiple patch-level updates during its three-year support period. Once released, we recommend updating to Qt 5.12 LTS for both current and new projects. We have convenient online binary installers in place so you can try out the upcoming features coming in Qt 5.12 LTS in its first beta state. We will continue to provide subsequent beta releases via the online installer. 

There is a huge number of things to talk about, so I’ll go through just some of the highlights of Qt 5.12 LTS in this blog post. For a more detailed overview of the new features coming in Qt 5.12 LTS, please check them out on the Qt 5.12 wiki page. We will also provide multiple blog posts and webinars for a more in-depth look at the Qt 5.12 LTS features.

Long-term support

Qt 5.12 LTS is a long-term supported release. It will be supported for three years, after which you can purchase extended support. As an LTS, it will receive multiple patch-level releases that provide bug fixes, improvements and security fixes. If you are about to begin a new project, you may want to start with Qt 5.12 LTS pre-releases already now. For ongoing projects, migration to Qt 5.12 LTS is recommended after it is released.

Qt 5.9 LTS entered ‘Strict’ phase at the beginning of February 2018. Going forward, Qt 5.9 will continue to receive critical bug and security fixes during the ‘Strict’ phase. We also continue to create new Qt 5.9.x patch releases during the ‘Strict’ phase, but at a slower cadence than before. The oldest Qt 5 LTS release, Qt 5.6 LTS, is in the last steps of the ‘Very Strict’ phase and has for a while received the most important security fixes only. There are no new patch releases currently planned for Qt 5.6 LTS. Those still using Qt 5.6 LTS should plan an update to a more recent version of Qt, as support of Qt 5.6 LTS ends in March 2019.

The reason for gradually reducing the amount of changes going into an LTS version of Qt is to avoid problems with stability. While each fix as such is beneficial, they also bring a risk for behavior changes and regressions, which we want to avoid in LTS releases.


Improved performance and reduced memory consumption have been important focus areas for Qt development already for Qt 5.9 LTS, and we have continued this for Qt 5.12 LTS. We have done multiple optimizations to the graphics and other functionalities, especially for running Qt 3D and Qt Quick on embedded hardware.

Qt 5.12 LTS provides good support for asset conditioning and improves upon the functionality introduced with Qt 5.10 and 5.11. One important new feature is the support for pre-generated distance field caches of fonts, which provides faster startup times, especially with complex and non-latin fonts.

The QML engine has also received multiple improvements and optimizations. Specifically, we focused on optimizing the memory consumption for Qt 5.12 LTS.


One of the most requested new controls is TableView and with Qt 5.12 LTS we finally provide it. The new TableView item is available in the Qt Quick module. TableView is similar to the existing ListView, but with additional support for showing multiple columns. We have developed the new TableView with performance in mind, with architecture that allows efficient handling of large tables. For a more detailed overview of the new TableView, please check the recent TableView blog post.

In addition to introducing the new TableView, Qt 5.12 LTS also provides multiple improvements and new features in Qt Quick Controls 2, as well as in the Qt VirtualKeyboard.

Input handling

With Qt 5.12 LTS, we introduce the new Input Handlers as a fully supported feature (earlier know as Pointer Handlers, a new approach for mouse, touch and gesture event handling). We have worked in this area for quite some time, and now it is ready for prime time. The main issue addressed with the new functionality is versatility, especially in multi-touch and multi-monitor applications. Those were areas where the previous functionalities have not been enough to tackle all use cases. The new functionalities enable many different input mechanisms in Qt applications, for example, based on hand gestures detected by a camera or a proximity sensor.

Input Handlers provides a QML API for recognizing and handling the most common mouse, touch and multi-touch gestures (press-hold-release, drag, swipe, and pinch) from mouse and touchscreen, in parallel across the scene. You can interact with multiple items simultaneously, across multiple screens when necessary. There is also a C++ API available, but that is still defined as a private API with Qt 5.12.

Python, Remote Objects and WebGL Streaming Plugin fully supported

Based on Qt 5.12 LTS we also provide an update to Qt for Python, initially released with Qt 5.11 as a technology preview. The Python community is very active and growing, so we are extremely happy to provide Qt for Python as a fully supported feature of Qt 5.12 LTS. You can get started conveniently with Qt for Python via the PyPI (Python Package Index).

In addition to Python, Qt Remote Objects and Qt WebGL Streaming Plugin are fully supported with Qt 5.12 LTS. Qt for WebAssembly continues to be a technology preview with Qt 5.12 LTS.

Tools for designers and developers

To get the maximum out of Qt 5.12 LTS we also have updates to our tooling underway. The upcoming Qt Design Studio 1.0 will will leverage a pre-release of Qt 5.12 LTS and will support final Qt 5.12 LTS when available. Qt Creator 4.8 is planned to be released together with Qt 5.12 LTS, offering a good set of new functionalities (e.g. support for multiple new programming languages and multiple simultaneous debugger sessions). As always, Qt Creator 4.8 will also work with earlier versions of Qt. In December we are releasing Qt 3D Studio 2.2, which is directly based on Qt 5.12 LTS and takes advantage of the numerous 3D related improvements of Qt 5.12 LTS.

Next steps towards the final release

After the Qt 5.12 LTS beta 1 released today, we will push out multiple new Beta N releases using the online installer. With this approach, it is easy for users to test the new features and provide feedback. During the beta phase, we expect to have new beta N releases within one to two weeks intervals. When we have reached a sufficient level of maturity we will create a release candidate of Qt 5.12 LTS. It will be made available directly via the online installer. We are not planning to publish separate blog posts for the subsequent beta releases and release candidate(s). In addition to binaries, source packages of each beta release are of course also available for those who prefer to build themselves.

Get Qt 5.12 LTS Beta

I hope many of you will install the Qt 5.12 LTS Beta releases, test and provide us your feedback to complete Qt 5.12 LTS. For any issues you may find, please submit a detailed bug report to bugreports.qt.io (please remember to mention which beta you found the issue with, check for duplicates and known issues). You are also welcome to join the discussions in the Qt Project mailing listsdeveloper forums and to contribute to Qt.

If you do not yet have the Qt online installer, get it from the Qt Account or from the Qt Download page.

The post Qt 5.12 LTS Beta Released appeared first on Qt Blog.

ICS talks Embedded UX Design, Hands-On Qt on Raspberry Pi, and more at Qt World Summit 2018 in Boston

Integrated Computer Solutions (ICS), the largest independent source of Qt expertise in North America, is proud to be a gold sponsor and training partner at The Qt World Summit Boston. We have big things planned for this important industry event. ICS CEO Peter Winston will share secrets learned from 500+ successful Qt projects, including a roadmap for prioritizing work and staffing projects. And we’ll share our experience using Qt to create voice-based user experiences for Amazon Alexa.

We’re also offering a full slate of pre-conference training sessions presented by our expert Qt instructors. Sessions cover a spectrum of topics, from the intro-level UX Design for Embedded Devices to specialized offerings, including Hands-on Qt on Raspberry Pi and Qt for Medical Devices.

Whatever your interest, ICS has a course to advance your Qt knowledge and help ensure your project’s success. Check out the full list:

  • Hands-on Qt on RaspberryPi (1 day)
  • Advanced QML (1 day)
  • UX Design for Embedded Devices (1 day)
  • Optimizing Qt Applications on Limited Hardware (½ day am)
  • High-Performance Applications with CAN Bus (½ day am)
  • Qt for Medical Devices (½ day pm)
  • Network Application Dev with ZeroMQ and Qt (½ day pm)

Want even more Qt? If you’re in town for The Qt World Summit, check out ICS’ latest 3-day training class, Implementing Modern Apps with Qt Quick, taking place in nearby Waltham on Oct. 31 – Nov. 2.

The post ICS talks Embedded UX Design, Hands-On Qt on Raspberry Pi, and more at Qt World Summit 2018 in Boston appeared first on Qt Blog.