How to Make tvOS Games & Apps with V-Play and Qt

tvOS is the smart TV operating system from Apple that let’s you play games and use apps on your Apple TV. Support for tvOS apps and games has been added to V-Play & Qt so now you can launch your cross-platform games and apps on your Apple TV too.

Get tvOS Support!

What is tvOS?

Apple based tvOS on iOS but it also includes a range of frameworks that are only supported on Apple TV. The company launched it in September 2015 alongside the 4th generation of Apple TV. The Apple TV is a device that acts as a digital media player and micro-console with a touch-screen interface.

tvOS lets you play games and use apps from your Apple TV. It offers a unique experience in comparison to a mobile device or tablet. It’s better suited than smaller devices at creating a shared experience for users. This is because the large screen allows multiple people to interact with it at the same time.

This shared experience is the focus of the tvOS user experience. You need to keep it in mind when you create your own tvOS apps and games.

Why Develop for tvOS?

There are many reasons why making tvOS apps and games make sense.

The Growing Popularity of Smart Homes

Smart devices like the Apple TV are only a small part of the Internet of Things that will become more popular in the next few years. Many companies are working on ways to make the home more intelligent. As this trend grows, Apple TVs and tvOS may become as popular in homes as the MacBook or iPad.

As it’s only been a little over a year since it’s release, tvOS is still a relatively young OS. While there’s no guarantee of success, it’s hard to see Apple letting one of Steve Job’s greatest passion projects fail.

These factors point to one thing for developers considering the tvOS marketplace. It’s an opportunity to place your apps and games on a platform with huge potential for growth.

A Lack of Competitors

It’s no secret that it’s becoming harder for apps and games to get seen on both Google Play and the App Store. It’s not just harder for your app to get discovered, cost-per-install is on the rise for most developers too.

There are other avenues available to mobile developers. But targeting a platform other than these two means entering into shrinking marketplaces. These marketplaces are already struggling for relevance and will do for years to come.

tvOS apps and games don’t have either of these problems. They exist in a small marketplace that still has the opportunity to grow.


Not having to worry so much about app store optimization and user acquisition is a bonus. It means you can invest more time in developing a great app rather than marketing. And as the marketplace grows, you’ll be in the right place to take advantage of it’s popularity

The Unique Monetisation Possibilities of tvOS

V-Play developers will know about all the mobile platforms they can launch their apps & games on. But it’s worth noting that you will also be able to port your existing apps and games to tvOS with minimal effort.

With it being so easy to bring your game or app to this new platform, you should know that it can be profitable too. Opportunities exist for both F2P and premium apps and games to make money from Apple TV users.

If your F2P game or app is doing well, it won’t hurt to get a little extra ad revenue by putting your app or game on Apple TV. The real benefit is for developers seeking to release premium apps and games.

Historically, people seem to have no problem paying to see stuff on their televisions. Whether it’s extra channels, pay per view events or apps and games. There seems to be less resistance to shelling out for something that appears on TV.


It’s also worth noting that Apple users are more likely to buy premium apps anyway. Paid apps make up 47% of the apps available for Apple TV. So some developers must have had success in this area already.

What to Know Before Getting Started

Before you get started on making your tvOS app, here are a few considerations to keep in mind.

The Big Screen Experience

Using an app or playing a game on a TV screen is a different experience than using a phone or tablet. Make sure you understand the differences before you start making your app or game. If possible, try out the Apple TV for yourself and test some games and apps to see what works best.

Remote Controls & How to Use Them

All Apple TVs come with a remote that’s used for navigation. The main feature of the remote is a touch surface that works extensively with swipe gestures. It also features  buttons for standard actions such as play/pause and volume up/down. You’ll need to consider if these navigation differences will affect the UX that your app or game provides.

Will you need to change the user interface for your app or game to accommodate the remote? It’s an important factor to consider before porting your app or game to tvOS. The purpose of the remote control is to make navigation seamless. This means you need to straighten out any hitches in your UI before you target the platform.

Keep Multiple Users in Mind

As mentioned, the Apple TV creates a shared experience; just like a traditional television set. There’s no such thing as creating a tvOS app or game for just one person. You need to be aware that there may be multiple users viewing your app or game at any time.

No Local Storage

tvOS apps have a maximum size of 200 MB and don’t make use of local storage. Instead, you need to stream app data from iCloud. Apps larger than 200MB can be packaged and loaded with On-Demand Resources. If you’re not a fan of a data-conscious approach, then tvOS apps mightn’t be for you.

tvOS Development with V-Play

You can develop apps and games for tvOS using the exact same V-Play workflow as you would for Android or iOS. You write your code in Qt Creator and deploy it from there to an Apple TV or simulator. Porting your existing games is easy too. tvOS support for V-Play uses the same API as the current SDK, so your game or app won’t change in any way when you port it to Apple TV.


V-Play is yet to support touch input but it supports a range of swipe gestures on remote control. V-Play mapped these gestures to the up/down/left/right keys of a keyboard. This makes it possible to test your game or app on desktop before deploying to Apple TV.

Nativeutils are fully implemented for tvOS. This makes it possible to show native confirmation dialogs and input dialogs in your app or game. This feature is essential for providing your users with a native UX.

V-Play added support for key events such as buttons and focus hints. This enables you to improve the UX of your app or game by making it easier for users to see which button is selected.

You can also add the Google Analytics plugin to your tvOS app or game in just a few minutes. See our documentation for more details on how to add this plugin with just a few lines of code.

tvOS Example Game – One Card!

V-Play has an example tvOS game on the App Store. V-Play released One Card! for iOS and Android but we were able to port it to tvOS with only minor additions to the source code.

The only change we needed to make was to add support for keyboard input (up, down, left, right, enter). We wanted this feature so it would be easy to test apps and games on desktop before deployment to Apple TV.

As there’s no point device available, we also added a focus hint for the currently active (selected) item, like the currently active card from the user’s stack or the selected menu item in the main menu.

Finally we added one of those shiny app icons with parallax effect, which are the essence of the Apple TV user experience All of these changes took less than a day. You can do the same with your V-Play games or apps!


One Card! uses V-Play Multiplayer, an all-in-one multiplayer component that adds the following features to your game:

You can use this open-source game example as the basis for all your multiplayer card games. You can access the free source code when you download V-Play.

You can download One Card! for tvOS here and view the source code in the V-Play SDK.

You can also play One Card! on Android and iOS devices
google_play_badge-1 itunes_download_link

Current V-Play developers can also find more info on One Card! in the V-Play documentation and the source code in the V-Play SDK here:

<Path to your V-Play SDK>/Examples/V-Play/demos/OneCard/

Get V-Play Support for tvOS Development

At the moment, tvOS development with V-Play is available to Enterprise customers only. Enterprise customers can access all V-Play Plugins and features and receive advanced support and training. Make sure to get in touch if you’d like to become an Enterprise customer and we can arrange your Enterprise evaluation today!

Get tvOS Support!

More Posts Like This!

16 Great Sites Featuring Free Game Graphics for Developers

game graphics

16 Great Websites Featuring Free Game Sounds for Developers

game sounds


21 Tips That Will Improve Your User Acquisition Strategy

User Acquisition

7 Useful Tips That Will Improve Your App Store Optimization

ASO screen capture

The post How to Make tvOS Games & Apps with V-Play and Qt appeared first on V-Play Engine.

Qt Creator 4.2 RC1 released

We are happy to announce the release of Qt Creator 4.2 RC1.

Since the release of the Beta, we’ve been busy with polishing things and fixing bugs. Just to name a few:

  • We fixed that the run button could spuriously stay disabled after parsing QMake projects.
  • Qt Creator is no longer blocked while the iOS Simulator is starting up.
  • We added preliminary support for MSVC2017 (based on its RC).

For an overview of the new features in 4.2 please head over to the Beta release blog post. See our change log for a more detailed view on what has changed.

Get Qt Creator 4.2 RC1

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

The post Qt Creator 4.2 RC1 released appeared first on Qt Blog.

Fuzzing Qt with libFuzzer

Disclaimer: I had this blog post in the drawer for several weeks now; I just held back with publishing it to give the Qt security team time to fix the reported issues (see below under 4.).
Inspired by the great talk from Hanno Böck aboutAmerican Fuzzy Lop and Address Sanitizer at QtCon, having a try on fuzzing Qt itself seemed like an interesting thing to do. For fuzzing different parts of a library like Qt, libfuzzer is a good choice: In contrast to e.g. American Fuzzy Lop, libfuzzer runs the test cases in the same process and does not need to spawn a new process for each test, which makes it very fast.
These are the steps to set up libFuzzer and test it on Qt:
1. Compile Qt with address sanitizer:
To get proper output when something is wrong (e.g. "heap user after free"), Qt needs to be built with address sanitizer. To enable this (and other sanitizers) with clang on Linux, the following patch has been applied:
diff --git a/mkspecs/linux-clang/qmake.conf b/mkspecs/linux-clang/qmake.confindex 77d913f..03d4c47 100644--- a/mkspecs/linux-clang/qmake.conf+++ b/mkspecs/linux-clang/qmake.conf@@ -11,6 +11,8 @@ include(../common/linux.conf)include(../common/gcc-base-unix.conf)include(../common/clang.conf)-QMAKE_LFLAGS += -ccc-gcc-name g++
+QMAKE_LFLAGS += -ccc-gcc-name g++ -fsanitize-coverage=edge -fsanitize=address+QMAKE_CFLAGS += -fsanitize-coverage=edge -fsanitize=address+QMAKE_CXXFLAGS += -fsanitize-coverage=edge -fsanitize=address
Even without using a fuzzer, compiling Qt and an application with those settings might highlight problems within the code.
Apparently the settings above are also available for gcc; also, it might be possible to specify those changes on the command line instead of patching the mkspec file.
2. build libfuzzer:
Libfuzzer is part of llvm, and has atutorial on how to build it. The resulting libFuzzer.a needs to be linked to the executables, as explained in the steps below.
3. write test cases:
For the fuzzing test cases, there is one function to be implemented, which will be called automatically by the fuzzer. Here is an example of a simple Qt test case:
#include <QtCore>#include <QtSvg>extern "C" int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) {QByteArray byteArrayData(reinterpret_cast<const char *>(Data), Size);QSvgRenderer renderer(byteArrayData);return 0;}
In particular, the test programs do not need a main() function, as it is already contained in libFuzzer.a. Here is the .pro file for the test case above:
TEMPLATE = appTARGET = QSvgRendererINCLUDEPATH += .QT += svg# InputSOURCES += qsvgrenderer.cppLIBS += -L/home/peter/dev/fuzzers -lFuzzer
The full set of Qt test cases written so far can be found on github:
This repository contains tests for QImage, QJsonDocument, QtNetwork and QXmlStreamReader, among others.
4. run and report results:
The test cases can be run using all available cores via e.g. "./QSvgRenderer -jobs=4 -workers=4 testcases". Also, the github repository above contains an initial set of test cases the fuzzer can start with. For instance when fuzzing SVG images, it makes sense to start with a valid SVG file as initial input.
The tests from the repository produced some issues in Qt, which have been reported to the Qt security mailing list or the Qt bugtracker (for stack traces and information on how to reproduce see the links):
QtDbus heap use-after-free(reported to the security mailing list on 16th of October 2016)
QJsonDocument heap buffer overflow(reported to the security mailing list on 19th of October 2016)
memory leak when creating an invalid SVG filereported to the Qt bug tracker on (23rd of October 2016)
Next steps:
A good way to improve results seems to look intouser-supplied mutatorsto have more control over which input is fed into the test cases. E.g. flipping bits seems like a good default way for binary data such as images, but when it comes to JSON or XML, there might be smarter ways to produce faulty input.

Fuzzing Qt for fun and profit

Many KDAB engineers are part of the Qt Security Team. The purpose of this team is to get notified of security-related issues, and then decide the best course of action for the Qt project.

Most of the time, this implies identifying the problem, creating and submitting a patch through the usual Qt contribution process, waiting for it to be merged in all the relevant branches, and then releasing a notice to the users about the extent of the security issue. We also work together with downstreams, such as our customers, Linux distributions and so on, in order to minimize the risks for Qt users of exposing the security vulnerability.

However, that’s only part of the story. As part of the security team, we can’t simply wait for reports to fall in our laps; we also need to have a proactive approach and constantly review our code base and poke it in order to find problems. For that, we use a variety of tools: the excellent Coverity Scan service; the sanitizers available in GCC and Clang; clazy, maintained by KDAB’s engineer Sérgio Martins; and so on.

Note that all these tools help catch any sorts of bugs, not only the security-related ones. For instance, take a look at the issues found and fixed by looking at the Undefined Behavior Sanitizer’s reports, and the issues fixed by looking at Coverity Scan’s reports.

Today I want to tell you a little more about one of the tools used to test Qt’s code: the American Fuzzy Lop, or AFL to friends.


What is AFL? It’s a fuzzer: a program that keeps changing the input to a test in order to make it crash (or, in general, misbehave). This “mutation” of the input goes on forever — AFL never ends, just keeps finding more stuff, and optimizes its own searching process.

AFL gained a lot of popularity because:

  • it is very fast (it instruments your binaries);
  • it uses state-of-the-art algorithms to mutate the input in ways that maximize the effect on the target program;
  • the setup is immediate;
  • it has a very nice text-based UI.

The results speaks for themselves: AFL has found security issues in all major libraries out there. Therefore, I decided to give it a try on Qt.

The setup

Setting up AFL is straightforward: just download it from its website and run make. That’s it — this will produce a series of executables that will act as a proxy for your compiler, instrumenting the generated binaries with information that AFL will need. So, after this step, we will end up with afl-gcc, afl-g++ and so on.

You can go ahead and build an instrumented Qt. If you’ve never built Qt from source, here’s the relevant documentation. On Unix systems it’s really a matter of running configure with some options, followed by make and optionally make install. The problem at this step is making Qt use AFL’s compilers, not the system ones. This turns out to be very simple, however: just export a few environment variables, pointing them to AFL’s binaries:

export CC=/path/to/afl-gcc
export CXX=/path/to/afl-g++
./configure ...

And that’s it, this will build an instrumented Qt. (A more thorough solution would involve creating a custom mkspec for qmake; this would have the advantage of making the final testscase application also use AFL automatically. For this task, however, I felt it was not worth it.)

Creating a testcase

What you need here is to create a very simple application that takes an input file from the command line (or stdin) and uses it to stress the code paths you want to test.

Now, when looking at a big library like Qt, there are many places where Qt reads untrusted input from the user and tries to parse it: image loading, QML parsing, (binary) JSON parsing, and so on. I decided to give a shot at binary JSON parsing, feeding it with AFL’s mutated input. The testcase I built was straightforward:

#include <QtCore>

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

    QFile file(app.arguments().at(1));
    if (!
        return 1;

    QJsonDocument jd = QJsonDocument::fromBinaryData(file.readAll());

    return 0;

Together with the testcase, you will also need a few test files to bootstrap AFL’s finding process. These files should be extremely small (ideally, 1-2KB at maximum) to let the fuzzer do its magic. For this, just dump a few interesting files somewhere next to your testcase. I’ve taken random JSON documents, converted them to binary JSON and put the results in a directory.

Running the fuzzer

Once the testcase is ready, you can run it into the fuzzer like this:

afl-fuzz -m memorylimit \
         -t timeoutlimit \
         [master/slave options] \
         -i testcases/ \
         -o findings/ \
         -- ./test @@

A few explanatory remarks:

  • The testcases directory contains your reference input files, while the findings of the fuzzers will be written in findings.
  • To avoid blowing up your system, AFL sets very strict limits for execution of your test: it is allowed to allocate at most memorylimit megabytes of virtual memory and it is allowed to run for at most timeoutlimit milliseconds. You will typically want to raise the memory limit from its default (50MB) to something bigger, depending on your system and on the test.
  • One instance of afl-fuzz is single threaded; in order to maximize the search throughput on a machine with multiple cores/CPUs, you must manually launch it multiple times with the same -i and -o arguments. You should also give each instance a unique name and, if you want, elect one instance to do a deterministic search rather than a random one. This is all expressed through the master/slave options: pass to one instance the -M fuzzername option, and to all the others pass the -S fuzzername option. (All the fuzzernames must be unique).
  • Last but not least, @@ gets replaced by the name of a file generated by AFL, containing the mutated input.

For reference, I’ve launched my master like this:

afl-fuzz -m 512 -t 20 -i testcases -o findings-json -M fuzzer00 -- ./afl-qjson @@

The output is a nice colored summary of what’s going on, updated in real time:

AFL running over a testcase.

AFL running over a testcase.

Now: go do something else. This is supposed to run for days! So remember to launch it in a screen session, and maybe launch it via nice so that it runs with a lower priority.


After running for a while, the first findings started to appear: inputs that crashed the test program or made it run for too long. Once AFL sees such inputs, it will save them for later inspection; you will find them under the findings/fuzzername subdirectories:


If you’re lucky (well, I guess it depends how you look at it…), you will end up with inputs that indeed crash your testcase. Time to fix something!

You may also get false positives, in the form of crashes because the testcase runs out of memory. Remember that AFL imposes a strict memory limit on your executable, so if your testcase allocates too much memory and does not know how to recover from OOM it will crash. If you see many inputs crashing into AFL but not crashing when running normally, maybe your testcase is behaving properly, but just running out of memory, and increasing the memory limit passed to AFL will fix this.

The sig part in the name of each saved input should give you a hint, telling you which Unix signal caused the crash. In the listing above, signal number 11 is a SIGSEGV, which is indeed a problem. The signal 06 is SIGABRT (that is, an abort), which was generated due to running out of memory.

To reproduce this last case, just manually run the test over that input, and check that it doesn’t misbehave; then rerun it, but this time limiting its available memory via ulimit -v memory_available_in_kilobytes. If the testcase works normally but crashes under a stricter ulimit, it’s likely that you’re in an out-of-memory scenario. This may or may not require a fix in your code; it really depends whether it makes sense for your application/library to recover from an OOM.

Fixing upstream

After reporting the findings to the Security Team, it was a matter of a few days before a fix was produced, tested and merged into Qt. You can find the patches here and here.

Tips and tricks

If you want to play with AFL, I would recommend you to do a couple of things:

  • Set your CPU scaling governor to “performance”. This is for a couple of reasons: it makes no sense for the kernel to try to throttle down your CPUs if AFL is running; and it is actually a bad thing because it interferes with AFL measurements. AFL complains about this, so keep it happy and disable “powersave” or “ondemand” or similar governors.
  • Use a ramdisk for the tests. AFL needs to write a new input file every time it runs your application; for the JSON testcase above, AFL was achieving about 1000 executions/second/core. Each of this run needs a new test file as input; in addition to that, AFL needs to write stuff for its own bookkeeping.This will put your disk under very considerable stress, possibly even wear it out. Now, any modern filesystem will still flush data to disk only a few times every second (at most), but still, why hit the disk at all? One can simply create a ramdisk, and run AFL in there:
    $ mkdir afl
    # mount -t tmpfs -o size=1024M tmpfs afl/
    $ cd afl/
    $ afl-fuzz -i inputs -o findings ...
  • Do not let this run on a laptop or some other computer which may overheat. AFL is tremendously resource intensive and runs for days. If you want to get liquid cooling for your workstation, this is the perfect excuse.


Fuzzing is an excellent technique for testing code that needs to accept untrusted inputs. It is straightforward to set up and run, requires no modifications to the tested code, and it can find issues in a relatively short timespan. If your application feature parsers (especially of binary data), consider to keep AFL running over it for a while, as it may discover some serious problems. Happy fuzzing!

About KDAB

KDAB is a consulting company offering a wide variety of expert services in Qt, C++ and 3D/OpenGL and providing training courses in:

KDAB believes that it is critical for our business to contribute to the Qt framework and C++ thinking, to keep pushing these technologies forward to ensure they remain competitive.

The post Fuzzing Qt for fun and profit appeared first on KDAB.

SpeedCrunch 0.12 Released

Almost 3 years and 700 000 downloads later, here's the core new features of this release:
If you're curious, check out the complete list of enhancements and bug fixes. Or go straight to the downloads page. For better productivity, learn about all the user interface quirks at your disposal.

MacOS users: please note that a download is not yet available for you. If you can help us with that, please get in touch.

Don't forget to report issues or request new features in our tracker. See more ways to contribute in the Help menu on the new website. Please help us release 1.0 as quickly as possible. Have a look at what's planned already.

Massive thank you to TeyutPol WelterFelix KrullHadrien, all the translators at Transifex, and the folks over at Portable Apps (for representing a nice chunk of our user base).


KDAB and Meiller – Tipper Truck App

Design, Technical Excellence and Superb User Experience

Why does a tipper truck need an app? Meiller is the leading manufacturer of tippers in Europe. KDAB software developers and UI/UX designers worked with Meiller to create a mobile app that interacts with embedded hardware on the truck, allowing drivers to diagnose and fix problems – even when on the road. KDAB shows us how technical excellence and stunning user experience go hand in hand.

The post KDAB and Meiller – Tipper Truck App appeared first on KDAB.

Qt World Summit 2016 Webinar Series – Christmas Sessions


‘Tis the season to be jolly and as always we are just trying to be Qt /kjuːt/. We just keep on giving and giving and here is another present for you. We are hosting webinars based on the breakout sessions from The Qt World Summit 2016. So, grab a cup of cocoa and sign up for our December Tuesday webinars where you can join our R&D developers online for technical sessions that will keep your computer warm throughout 2017. The best thing of all – even if you can’t make it online – by signing up Santa will bring the recorded session to you.

Introducing Qt Visual Studio Tools

December 6th at 5 pm CET, by Maurice Kalinowski

New possibilities with Qt WebEngine

December 13th at 5 pm CET, by Allan Sandfeld Jensen

Qt Quick Scene Graph Advancements in Qt 5.8 and Beyond 

December 20th at 10 am CET (Rescheduled from November 15th), by Laszlo Agocs


Also, stay tuned for details on upcoming webinars in January!

Make sure to check our events calendar for the full list of Qt-related events delivered by us and our partners.

The post Qt World Summit 2016 Webinar Series – Christmas Sessions appeared first on Qt Blog.

Captain obvious: Sign a contract before starting to work

I have worked as a freelancer for more than a decade and was very very fortunate with the projects and partners I had. I apparently let my guards down a little bit too much and this is a reminder what to look-out for.

I have nice memories working with the Trolltech PSO team and helping with architecture, performance and low-level debugging in South Korea but when Nokia stopped investing into Qt my work on Qt and QtWebKit halted and I moved to work exclusively on GSM/3G systems. Through linkedin I got approached by a Korean business owner that spent some time working in Norway and for some companies well known to (old) Qt developers with something that looked like an opportunity to pick-up my old work. Given the common background and my work in Korea I immediately trusted this person.

I have a thing for tight deadlines and some forms of death march projects and was curious of how much the landscape changed. I thought we agreed on times and material for an exploration phase to see if the rest of the project is feasible and depending on the result move on or not, HW was sent and while there was no signed agreement I began to work. The exploration was fun but the setting was difficult and turns out there was no intention to pay for the exploration phase.

Which brings me to things I have to remember and want to share with you:

  • Don’t start to work before there is a written and signed agreement
  • If there is a tight deadline the burden on making the contract is on your customer and not you. If the contract is too long to read, reject it.
  • Don’t take the risk of unpaid exploration if you have no influence on the final project

Desktops DevRoom @ FOSDEM 2017: you are still on time to submit a talk

FOSDEM 2016 is going to be great (again!) and you still have the chance to be one of the stars.

Have you submitted your talk to the Desktops DevRoom yet?


Remember: we will only accept proposals until December 5th. After that, the Organization Team will get busy and vote and choose the talks.

Here is the full Call for Participation, in case you need to check the details on how to submit:

FOSDEM Desktops DevRoom 2017 Call for Participation

Topics include anything related to the Desktop: desktop environments, software development for desktop/cross-platform, applications, UI, etc

Cutelyst benchmarks on TechEmpower round 13

Right on my first blog post about Cutelyst users asked me about more "realistic" benchmarks and mentioned TechEmpower benchmarks. Though it was a sort of easy task to build the tests at that time it didn't seem to be useful to waste time as Cutelyst was moving target.

Around 0.12 it became clear that the API was nearly freezing and everyone loves benchmarks so it would serve as a "marketing" thing. Since the beginning of the project I've learned lots of optimizations which made the code get faster and faster, there is still room from improvement, but changes now need to be carefully measured.

Cutelyst is the second Web Framework on TechEmpower benchmarks that uses Qt, the other one being treefrog, but Qt's appearance was noticed on their blog:

The cutelyst-thread tests suffered from a segfault (that was restarted by master process), the fix is in 1.0.0 release but it was too late for round 13, so round 14 it will get even better results.

If you want to help MongoDB/Grantlee/Clearsilver tests are still missing :D

Release 2.9.2: Qt World Summit 2016 App Showcase and New App Components

V-Play 2.9.2 is now available to download. It adds the open-source Qt World Summit 2016 Conference app example, a range of new V-Play Apps components and a number of improvements and fixes.

The Qt World Summit 2016 Conference App was created by the V-Play team. It allowed developers attending this year’s event to get an overview of the talks that were happening, find information about speakers and create their own schedule. The source code of this app is available as an open-source app example when you download or update to V-Play 2.9.2.

V-Play 2.9.2 also adds a new range of V-Play Apps components. You can now enjoy native-looking search functions, tab bars, list views and more. Get it now for free and try out these new features for yourself!

Update Now!

Qt World Summit 2016 Conference App Example

This new app example is available as an open-source demo and can be used as the basis for your own mobile apps. Along with it’s primary function as a scheduling tool, it also includes an in-app chat feature, personalization features and gamification features that are sure to boost app engagement.


This cross-platform app includes the following features:

  • Browse the conference schedule.
  • See detailed information for all talks, speakers and tracks.
  • Manage your personal schedule by adding talks to your favorites.
  • Customize the UI and switch between different native styles and colors.
  • Earn points for each app-start and favorited talk to climb the leaderboard.
  • Make friends and send messages with the integrated in-app chat.

Viewing this app example is a great way to get acquainted with the best practices of developing a V-Play app and see how a native UI & UX looks with an app developed with V-Play.

apps-demo-qtws-ios-2 apps-demo-qtws-ios-3 apps-demo-qtws-ios-4

apps-demo-qtws-android-2 apps-demo-qtws-android-3 apps-demo-qtws-android-4

You can learn how to handle app specific requirements such as offline capability, how to use native device features like confirmation dialogs and how to use a single codebase to create an app that’s supported across multiple platforms, screen sizes and screen resolutions.

To get a look at the Qt World Summit 2016 Conference app in action, you can download it from either the App Store or Google Play using the links below. The app is free to download so get it now!

google_play_badge-1 itunes_download_link

It’s also available to download from GitHub:


New V-Play Apps Components

V-Play Apps has added a number of new app components in this latest update to give your cross-platform apps the same look and feel as native apps for iOS and Android. This means you can create the perfect user experience for both platforms at the same time.

  • Create native-looking tabs with the new AppTabBar and AppTabButton components that also support a swipe-able content view.

apptabbar-control-ios apptabbar-control-android

  • Add a search feature by integrating the SearchBar component with Theme-based styles for iOS and Android.

searchbar-control-ios searchbar-control-android

sectionselect-control-ios sectionselect-control-android

  • Use the AppFlickable to add a native looking rebound effect to your scrolling.

appflickable-ios appflickable-android

textbuttonbaritem-control-ios textbuttonbaritem-control-android

  • Add a material-design styled FloatingActionButton to provide quick access to your Android app’s most important features.


V-Play 2.9.2 also comes with improvements and fixes to V-Play Apps such as iOS 10 haptic feedback, navigation bug fixes and dialog bug fixes. For a full list of additions, improvements and fixes to V-Play Apps, check out our change log!

V-Play Game Engine Improvements

With V-Play 2.9.2, you can now check to see if your game is online with the GameWindow::isOnline property.

V-Play Multiplayer and the V-Play Game Network are also now fully compatible with V-Play Apps projects and an issue that was occurring on some Android devices with the BackgroundMusic component is now fixed.

V-Play Plugins Improvements

The latest version of V-Play now supports the most up-to-date Facebook plugin. You can use a new signal with this plugin called Facebook::sessionOpened, that gives you more information about what happens during an opened session.

V-Play 2.9.2 also includes improvements and fixes for existing V-Play Plugins. The platform libraries of the AdMob and HockeyApp plugins have been updated to the latest versions. V-Play Apps developers will also have the option to display customized notification icons with Google Cloud Messaging and OneSignal.

A full list of fixes for V-Play Plugins can be seen in the V-Play change log!

How to Update

Test out these new features by following these steps
Step 1
Open the V-Play SDK Maintenance Tool in your V-Play SDK directory. Choose “Update components” and finish the update process to get V-Play 2.9.2 as described in the V-Play Update Guide.
If you haven’t installed V-Play yet, you can do so now with the latest installer from here.
Step 2
The V-Play Sample Launcher allows you to quickly test and run all the open-source examples and demo apps & games that come with the V-Play SDK, from a single desktop application.
After installing V-Play, you can start the V-Play Sample Launcher from the application shortcut in your V-Play SDK directory.
Now you can explore all of the new features included in V-Play 2.9.2!
For a complete list of the changes to V-Play with this update, please check out our change log!

More Posts Like This!

16 Great Sites Featuring Free Game Graphics for Developers

game graphics

16 Great Websites Featuring Free Game Sounds for Developers

game sounds


21 Tips That Will Improve Your User Acquisition Strategy

User Acquisition

7 Useful Tips That Will Improve Your App Store Optimization

ASO screen capture

The post Release 2.9.2: Qt World Summit 2016 App Showcase and New App Components appeared first on V-Play Engine.

CMake support in Qt Creator (and elsewhere?)

Kitware released CMake version 3.7 on Friday night. There is one feature mentioned at the very bottom of the feature list that makes this a really exciting release for people writing tools that integrate with CMake: The server-mode.

What is CMake server-mode?

The Qt Creator team has had contact with the CMake community for a long time now and was actively involved in discussions with CMake and other IDE and tools vendors. After many discussions the CMake community decided that the best way forward to support the use-cases of IDEs was to add a new interactive way to interact with CMake, the so called server-mode. There was some initial development started by Stephen Kelly, who made an impressive prototype.

At this point the Qt Creator team decided that this functionality is crucial to enable first class CMake support in Qt Creator. So I went ahead and jumped into CMake development. The result is a set of patches that implement a production-ready server-mode for CMake that was merged in time for the CMake 3.7 release. The server-mode currently focuses on core functionality like parsing the project structure, etc.

This development happened in close collaboration with developers from KDevelop and the CMake community.

I am committed to maintain CMake server-mode support going forward and hope to continue to develop this feature in close collaboration with all interested parties.

CMake version 3.7 is the first release that ships this code.

What does CMake 3.7 enable?

The first change in CMake 3.7 is that it now provides machine-readable output with basic information about the capabilities of the CMake binary (via “cmake -E capabilities”).

This includes static information like version number or whether server-mode is available, but also details on the supported generators.

IDEs can use this information to provide a better UI for selecting generators.

CMake server-mode (started via “cmake -E server”) allows IDEs to query a range of CMake settings and project information in a machine-readable form, many of which were not available to IDEs before. This enables a more detailed view of the CMake project.

The information is also taken from CMake directly, making sure to use the same code that is also used by the CMake generators to write the actual build-system files. So the information is more accurate than what was available before. This makes the code model more exactly represent what is actually going to be built.

When will we see these improvements in action?

I think the server-mode is the way forward for all tools that need to extract information from CMake. Interest in this topic seemed very strong in my workshop about CMake at QtCon this year. I hope to see CMake server-mode flourish going forward.

There is code that makes use of the new CMake 3.7 features in the master branch of Qt Creator. So this will be present in Qt Creator 4.3, planned for spring of 2017.

What will improve in Qt Creator?

Creator will continue to support any CMake version 3.0 (or later), just as current versions of Qt Creator do. But Qt Creator master does support CMake server-mode already and will make use of the better information. You will be able to switch between CMake binaries with and without server-mode support as needed.

Using CMake server-mode enabled binaries will have the following effects:

  • Generator selection is no longer limited to those generators with support for the “CodeBlocks” extra generator. Any generator can now be used.
    CMake Generator setup in Qt Creator

    CMake Generator setup in Qt Creator

  • The Generator selection UI now knows which options are available for each generator. E.g. the “Ninja” generator used above does not support Toolsets or Platform settings.
  • The project tree is much improved and knows about projects and build targets defined in CMake."<yoastmarkThe screenshots show the project tree from Qt Creator 4.2 and from Qt Creator master — with an old CMake and with CMake server-mode.
    Qt Creator master adds all headers found in include paths of a build target and not listed in the CMakeLists.txt to the project tree (for all versions of CMake). These headers are printed with a grey text color so they can be distinguished from sources known to CMake.
    In server-mode the project structure is more visible: The “scribus” project defined in the top-level CMakeLists.txt file is clearly visible. So are the different build targets. The “scribus_colormgmt_lib” build target is expanded and all files belonging to that target are listed.
  • The code model has way more accurate information about all targets. This sounds very simple, but has not always been the case for CMake projects up to now.

What will happen next with CMake server-mode?

Stephen Kelly has pioneered interesting features in his CMake server-mode implementation prototype. Many did not make it into the new CMake release.

Going forward I would like to see more of these powerful features. This includes debugging of CMakeLists.txt files and syntax highlighting driven by CMake itself. These require deep integration into CMake and will require a much deeper understanding of CMake internals than I currently have. So I hope CMake developers find the server-mode interesting enough to help out a bit here and there:-)

I would like to say thanks to Aleix Pol (KDevelop) and Stephen Kelly (CMake community) for all the feedback they provided. Finally I have to thank Brad King from Kitware for his patience while  reviewing my code.

Where can I get this?

Get CMake 3.7 here:
View the Qt Creator master sources:
Or use git to clone the code: git clone git://

The post CMake support in Qt Creator (and elsewhere?) appeared first on Qt Blog.

See you at Meeting C++ 2016?

KDAB is again a proud gold sponsor of this year’s Meeting C++ conference, on the 18th and 19th of November.


This year’s program features no less than 33 talks, divided into 5 tracks. The conference will be opened with a keynote by Bjarne Stroustrup himself, the ideator of the C++ programming language, and will close with a keynote by Louis Dionne, author of the Boost.Hana metaprogramming library. Also, don’t miss the lightning talks and the official lounge track :).

The conference will be held at the Andels Hotel in Berlin. See you there!

The post See you at Meeting C++ 2016? appeared first on KDAB.

Qt Visual Studio Tools 2.0 Released

Today we are releasing Qt Visual Studio Tools 2.0. This is mainly a release moving the functionality of the old Visual Studio Add-In to newer versions of Visual Studio. In addition to some minor bug fixes the Qt Visual Studio Tools now support Visual Studio 2013 and Visual Studio 2015. The commercial version of the Add-In has been merged and there is now also support for Qt Quick (QML) in the free version of the tools. We also made them available through the Visual Studio Gallery. The version for Visual Studio 2013 can be downloaded here, while you can get the Visual Studio 2015 Version here.


Main Changes:

  • Supports Visual Studio 2013 and 2015
  • Major code refactoring, build system updates, and code cleanup
  • New wizard system based on the Visual Studio extension system
  • Out of the box support for Qt Type C++ Debugger Visualizers (natvis)
  • QML highlighting support
  • F1 help support

Known Issues:

  • Missing localization support
  • Supports only installed versions of Qt
  • Dropped support for older Visual Studio versions and Windows CE

Get the Qt VS Tools

The Qt Company has prepared convenient installers for the Qt Visual Studio Tools 2.0. You can download it from your Qt Account or from They are also available from the Visual Studio Gallery for Visual Studio 2013 and Visual Studio 2015.

For any issues you may find with the release, please submit a detailed bug report to (after checking for duplicates). You are also welcome to join the discussions in the Qt Project mailing lists, development forums and to contribute to Qt.

The post Qt Visual Studio Tools 2.0 Released appeared first on Qt Blog.

Over-the-Air Updates, Part 3: Repository Configuration and Handling

Part one of the blog post series introduced the challenges of implementing an update system. We looked at the OSTree project and how it can help us to bring system update functionality to Qt for Device Creation. The second part demonstrated the tooling and the API that is provided by the Qt OTA Update module. We ended the second blog post by demonstrating how to generate an update. In this blog post we will export the generated update on a static HTTP server and configure a client device to query this server for system updates. Following this will be a short history lesson on OSTree adoption in the Linux ecosystem. But first we will take a quick look at what’s new in the Qt OTA Update module since the Technology Preview release.

Status Update.

Starting with Qt 5.8 for Device Creation, the Qt OTA Update module is graduating from being a Technology Preview module to a fully supported module. Some of the new features and improvements in Qt OTA Update 1.0 are: initramfs no longer being a hard requirement for using the OTA update feature (desirable when optimizing boot time), new API for configuring how remote OSTree repositories are accessed, more status notifications from the update process for the convenience of users, some minor API renamings, improved demo application and new command line arguments for the qt-ostree tool (for fine-tuning the image and update generation).

Exporting Repository.

As mentioned earlier, we ended the second blog post by generating a new update. An update (or a system snapshot) is a commit into OSTree repository. By default, qt-ostree stores this repository in WORKDIR/ostree-repo/. For local testing you can pass --start-trivial-httpd to qt-ostree. This starts a simple HTTP server which is accessible on the local host at the address specified in the WORKDIR/httpd/httpd-address file. In a real world scenario you would want to export this repository on a production server. This is as simple as copying the contents of the WORKDIR/ostree-repo/ directory to a dedicated path on the server.

The --start-trivial-http does not have support for HTTPS so I have configured my own Apache web server. This server requires TLS client side authentication. A URL to the OSTree repository in my case is Because the configured web server resides on my development machine, the ostree-repo/ directory from the URL is conveniently a symlink to WORKDIR/ostree-repo/. Whenever I generate a new system snapshot, it is immediately available on The next step is to point client devices to this address.

Configuring Devices.

Extending on the demo from the previous blog post, we need to add a configuration that describes how to access the server:

OtaRepositoryConfig {
    id: secureConfig
    gpgVerify: true
    url: ""
    tlsClientCertPath: "/usr/share/ostree/certs/clientcert.pem"
    tlsClientKeyPath: "/usr/share/ostree/certs/clientkey.pem"
    tlsPermissive: false
    tlsCaPath: "/usr/share/ostree/certs/servercert.pem"

Here we are pointing the client device to the URL where we exported the generated OSTree repository. This configuration requires the update to be signed by a known GPG key. We also provide paths to the certificate files (on the device) which are used for client and server TLS authentication. A keyring with the trusted keys and certificate pinning should be done when creating the initial image (during the device integration step). The current configuration can be updated by calling:

OtaClient.setRepositoryConfig(OtaRepositoryConfig config)

The subsequent calls to the server (for example, fetching metadata about the remote snapshot) will use this updated configuration.

An alternative configuration could use unencrypted HTTP and look as follows:

OtaRepositoryConfig {
    id: basicConfig
    url: ""

If we exported the repository to scheme://host:port/my-product/system-updates/, we would point devices to that URL instead. The complete demo application is available here.

OSTree Adoption.

System updates are an everlasting area of interest. Just look at the talks dedicated to this topic on the Embedded Linux Conference this year (and the years before). OSTree was amongst the presented alternatives, receiving great feedback due to its outstanding approach. OSTree originated as a research venture in high speed continuous delivery and testing infrastructure for GNOME. It has been a well-received technology with expanding adoption in the Linux ecosystem. OSTree is being used at the core of new Linux distributions – Project Atomic, Endless OS, Papyros. Automotive Grade Linux is researching OSTree integration for the AGL reference platform. Flatpak (a framework for distributing Linux applications) is another interesting project that uses OSTree to distribute and manage applications and runtimes. As we can see, OSTree is hot technology, being adopted by a variety of projects on desktop, servers and embedded systems.

Want to have a robust and modern update system on your devices as well? The Qt OTA Update 1.0 module brings full OSTree support with convenient Qt APIs to Qt 5.8 for Device Creation.


This concludes the series of the blog posts introducing the Qt OTA Update module. Try it yourself with Qt for Device Creation and let us know what you think. Feedback and feature requests are always welcome and appreciated.

The post Over-the-Air Updates, Part 3: Repository Configuration and Handling appeared first on Qt Blog.

Cutelyst 1.0.0 with stable API/ABI is out!

Cutelyst the Qt web framework just reached it's first stable release, it's been 3 years since the first commit and I can say it finally got to a shape where I think I'm able to keep it's API/ABI stable. The idea is to have any break into a 2.0 release by the end of next year although I don't expect many changes as the I'm quite happy with it's current state.

The biggest change from the last release is the SessionStoreFile class, it initially used QSettings for it's simplicity but it was obvious that it's performance would be far from ideal, so I replaced QSettings with a plain QFile and QDataStream, this produced smaller session files and made the code twice as fast, but profiling was showing it was still slow because it was writing to disk multiple times on the same request. So the code was changed to merge the changes and only save to disk when the Context get's destroyed, on my machine the performance went from 3,5k to 8.5k on read and writes and 4k to 12k on reads, this is on the same session id, should probably be faster with different ids. This is also very limited by the disk IO as we use a QLockFile to avoid concurrency, so if you need something faster you can subclass SessionStore and use Sql or Redis...

Besides that the TechEmpower 13th preview rounds showed a segfault in the new Cutelyst WSGI in threaded mode, a very hard to reproduce but with an easy fix. The initial fix made the code a bit ugly so I searched to see if XCode clang got an update on thread_local feature and finally, XCode 8 has support for it, if you are using XCode clang now you need version 8.

Many other small bugs also got in and API from 0.13.0 is probably unchanged.

Now if you are a distro packager please :D package it, or if you are a dev and was afraid of API breaks keep calm and have fun!


Qt on the NVIDIA Jetson TX1 – Device Creation Style

NVIDIA’s Jetson line of development platforms is not new to Qt; a while ago we already talked about how to utilize OpenGL and CUDA in Qt applications on the Jetson TK1. Since then, most of Qt’s focus has been on the bigger brothers, namely the automotive-oriented DRIVE CX and PX systems. However, this does not mean that the more affordable and publicly available Jetson TX1 devkits are left behind. In this post we are going to take a look how to get started with the latest Qt versions in a proper embedded device creation manner, using cross-compilation and remote deployment for both Qt itself and applications.


The photo above shows our TX1 development board (with a DRIVE CX sitting next to it), hooked up to a 13″ touch-capable display. We are going to use the best-supported, Ubuntu 16.04-based sample root filesystem from Linux for Tegra R24.2, albeit in a bit different manner than what is shown here: instead of going for the default approach based on OpenGL + GLX via the xcb platform plugin, we will instead set up Qt for OpenGL ES + EGL via the eglfs. Our applications will still run on X11, but in fullscreen. Instead of building or developing anything on the device itself, we will follow the standard embedded practice of developing and cross-compiling on a Linux-based host PC.

Why this approach?

  • Fast. While building on target is fully feasible with all the power the TX1 packs, it is still no match for compiling on a desktop machine.
  • By building Qt ourselves we can test the latest version, or even unreleased snapshots from git, not tied to the out-of-date version provided by the distro (5.5).
  • This way the graphics and input device configuration is under control: we are after EGL and GLES, with apps running in fullscreen (good for vsync, see below) and launched remotely, not a desktop-ish, X11-oriented build. We can also exercise the usual embedded input stack for touch/mouse/keyboard/tablet devices, either via Qt’s own evdev code, or libinput.
  • While we are working with X11 for now, the custom builds will allow using other windowing system approaches in the future, once they become available (Wayland, or just DRM+EGLDevice/EGLOutput/EGLStream).
  • Unwanted Qt modules can be skipped: in fact in the below instructions only qtbase, qtdeclarative and qtgraphicaleffects get built.
  • Additionally, with the approach of fine-grained configurability provided by the Qt Lite project, even the must-have modules can be tuned to include only the features that are actually in use.

Setting Up the Toolchain

We will use L4T R24.2, which features a proper 64-bit userspace.

After downloading Tegra210_Linux_R24.2.0_aarch64.tbz2 and Tegra_Linux_Sample-Root-Filesystem_R24.2.0_aarch64.tbz2, follow the instructions to extract, prepare and flash the device.

Verify that the device boots and the X11 desktop with Unity is functional. Additionally, it is strongly recommended to set up the serial console, as shown here. If there is no output on the connected display, which happened sometimes with our test display as well, it could well be an issue with the HDMI EDID queries: if running get-edid on the console shows no results, this is likely the case. Try disconnecting and reconnecting the display while the board is running.

Once the device is ready, we need a toolchain. For instance, get gcc-linaro-5.3.1-2016.05-x86_64_aarch64-linux-gnu.tar.xz from Linaro (no need for the runtime or sysroot packages now).

Now, how do we add more development files into our sysroot? The default system provided by the sample root file system in Linux_for_Tegra/rootfs is a good start, but is not sufficient. On the device, it is easy to install headers and libraries using apt-get. With cross-compilation however, we have to sync them back to the host as well.

First, let’s install some basic dependencies on the device:

sudo apt-get install '.*libxcb.*' libxrender-dev libxi-dev libfontconfig1-dev libudev-dev

Then, a simple option is to use rsync: after installing new -dev packages on the target device, we can just switch to rootfs/usr on the host PC and run the following (replacing the IP address as appropriate):

sudo rsync -e ssh -avz ubuntu@ .
sudo rsync -e ssh -avz ubuntu@ .

Almost there. There is one more issue: some symbolic links in rootfs/usr/lib/aarch64-linux-gnu are absolute, which is fine when deploying the rootfs onto the device, but pretty bad when using the same tree as the sysroot for cross-compilation. Fix this by running a simple script, for instance this one. This will have to be done every time new libraries are pulled from the target.

Graphics Considerations

By default Qt gets configured for GLX and OpenGL (supporting up to version 4.5 contexts). For EGL and OpenGL ES (up to version 3.2) we need some additional steps first:

The headers are missing by default. Normally we would install packages like libegl1-mesa-dev, however it is likely safer to avoid this and not risk pulling in the Mesa graphics stack, potentially overwriting the NVIDIA proprietary binaries. Run something like the following on the device:

apt-get download libgles2-mesa-dev libegl1-mesa-dev
ar x ...
tar xf data.tar.xz (do this for both)
sudo cp -r EGL GLES2 GLES3 KHR /usr/include

then rsync usr/include back into the sysroot on the host.

Library-wise we are mostly good, except one symlink. Do this on the device in /usr/lib/aarch64-linux-gnu:

sudo ln -s /usr/lib/aarch64-linux-gnu/tegra-egl/

then sync the libraries back as usual.

Qt can now be configured with -opengl es2. (don’t be misled by “es2”, OpenGL ES 3.0, 3.1 and 3.2 will all be available as well; Qt applications will get version 3.2 contexts automatically due to the backwards compatible nature of OpenGL ES)

Configuring and Building Qt

Assuming our working directory for L4T and the toolchain is $HOME/tx1, check out qtbase into $HOME/tx1/qtbase (e.g. run git clone git:// -b dev – using the dev branch, i.e. what will become Qt 5.9, is highly recommended for now because the TX1 device spec is only present there) and run the following:

-device linux-jetson-tx1-g++
-device-option CROSS_COMPILE=$HOME/tx1/gcc-linaro-5.3.1-2016.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-
-sysroot $HOME/tx1/Linux_for_Tegra/rootfs
-nomake examples
-nomake tests
-prefix /usr/local/qt5
-extprefix $HOME/tx1/qt5
-hostprefix $HOME/tx1/qt5-host
-opengl es2

Note the dash at the end of the CROSS_COMPILE device option. It is a prefix (for aarch64-linux-gnu-gcc and others) so the dash is necessary.

This will be a release build. Add -force-debug-info if debug symbols are needed. Switching to full debug builds is also possible by specifying -debug.

Check the output of configure carefully, paying extra attention to the graphics bits. Below is an extract with an ideal setup:

Qt Gui:
  FreeType ............................... yes
    Using system FreeType ................ yes
  HarfBuzz ............................... yes
    Using system HarfBuzz ................ no
  Fontconfig ............................. yes
  Image formats:
    GIF .................................. yes
    ICO .................................. yes
    JPEG ................................. yes
      Using system libjpeg ............... no
    PNG .................................. yes
      Using system libpng ................ yes
    EGL .................................. yes
    Desktop OpenGL ....................... no
    OpenGL ES 2.0 ........................ yes
    OpenGL ES 3.0 ........................ yes
    OpenGL ES 3.1 ........................ yes
  Session Management ..................... yes
Features used by QPA backends:
  evdev .................................. yes
  libinput ............................... no
  mtdev .................................. no
  tslib .................................. no
  xkbcommon-evdev ........................ no
QPA backends:
  DirectFB ............................... no
  EGLFS .................................. yes
  EGLFS details:
    EGLFS i.Mx6 .......................... no
    EGLFS i.Mx6 Wayland .................. no
    EGLFS EGLDevice ...................... yes
    EGLFS GBM ............................ no
    EGLFS Mali ........................... no
    EGLFS Rasberry Pi .................... no
    EGL on X11 ........................... yes
  LinuxFB ................................ yes
  Mir client ............................. no
    Using system provided XCB libraries .. yes
    EGL on X11 ........................... yes
    Xinput2 .............................. yes
    XCB XKB .............................. yes
    XLib ................................. yes
    Xrender .............................. yes
    XCB render ........................... yes
    XCB GLX .............................. yes
    XCB Xlib ............................. yes
    Using system-provided xkbcommon ...... no
Qt Widgets:
  GTK+ ................................... no
  Styles ................................. Fusion Windows

We will rely on EGLFS and EGL on X11 so make sure these are enabled. Having the other X11-related features enabled will not hurt either, a fully functional xcb platform plugin can come handy later on.

Now build Qt and install into $HOME/tx1/qt5. This is the directory we will sync to the device later under /usr/local/qt5 (which has to match -prefix). The host tools (i.e. the x86-64 builds of qmake, moc, etc.) are installed into $HOME/tx1/qt5-host. These are the tools we are going to use to build applications and other Qt modules.

make -j8
make install

On the device, create /usr/local/qt5:

mkdir /usr/local/qt5
sudo chown ubuntu:ubuntu qt5

Now synchronize:

rsync -e ssh -avz qt5 ubuntu@

Building Applications and other Qt Modules

To build applications, use the host tools installed to $HOME/tx1/qt5-host. For example, go to qtbase/examples/opengl/qopenglwidget and run $HOME/tx1/qt5-host/bin/qmake, followed by make. The resulting aarch64 binary can now be deployed to the device, via scp for instance: scp qopenglwidget ubuntu@

The process is same for additional Qt modules. For example, to get Qt Quick up and running, check out qtdeclarative (git clone git:// -b dev) and do qmake && make -j8 && make install. Then rsync $HOME/tx1/qt5 like we did earlier. Repeat the same for qtgraphicaleffects, this will be needed by the Cinematic Experience demo later on.

Running Applications

We are almost ready to launch an application manually on the device, to verify that the Qt build is functional. There is one last roadblock when using an example from the Qt source tree (like qopenglwidget): these binaries will not have rpath set and there is a Qt 5.5.1 installation on the device, right there in /usr/lib/aarch64-linux-gnu. By running ldd on our application (qopenglwidget) it becomes obvious that it would pick that Qt version up by default. There are two options: the easy, temporary solution is to set LD_LIBRARY_PATH to /usr/local/qt5/lib. The other one is to make sure no Qt-dependent processes are running, and then wipe the system Qt. Let’s choose the former, though, since the issue will not be present for any ordinary application as those will have rpath pointing to /usr/local/qt5/lib.

The default platform plugin is eglfs, with the eglfs_x11 backend, which does not do more than opening a fullscreen window. This is good enough for most purposes, and also eliminates one common source of confusion: the lack of vsync for non-fullscreen windows. In the default X11-based system there is apparently no vertical synchronization for OpenGL content, unless the window is fullscreen. This is the same behavior like with the Jetson TK1. Running the qopenglwidget example in a regular window will result in an unthrottled rendering rate of 500-600 FPS. Changing to showFullScreen() triggers the expected behavior, the application gets throttled to 60 FPS. Qt Quick is problematic in particular, because the default and best, threaded render loop will result in bad animation timing if vsync-based throttling is not active. This could be worked around by switching to the less smooth basic render loop, but the good news is that with eglfs the problem will not exist in the first place.

Input is handled via evdev, skipping X11. The device nodes may need additional permissions: sudo chmod a+rwx /dev/input/event* (or set up a udev rule). To debug the input devices on application startup, do export QT_LOGGING_RULES=qt.qpa.input=true. If needed, disable devices (e.g. the mouse, in order to prevent two cursors) from X11 via the xinput tool (xinput list, find the device, find the enabled property with xinput list-props, then change it to 0 via xinput set-prop).

And the end result:

qopenglwidget, a mixed QWidget + QPainter via OpenGL + custom OpenGL application

The Qt 5 Cinematic Experience demo (sources available on GitHub) for Qt Quick, with fully functional touch input

Qt Creator

Building and deploying applications manually from the terminal is nice, but not always the most productive approach. What about Qt Creator?

Let’s open Qt Creator 4.1 and the Build & Run page in Options. At minimum, we have to teach Creator where our cross-compiler and Qt build can be found, and associate these with a kit.

Go to Compilers, hit Add, choose GCC. Change the Name to something more descriptive. The Compiler path is the g++ executable in our Linaro toolchain. Leave ABI unchanged. Hit Apply.


Now go to Qt Versions, hit Add. Select qmake from qt5-host/bin. Hit Apply.


Go to Kits, hit Add. Change the Name. Change the Device type to Generic Linux Device. Change Sysroot to Linux_for_Tegra/rootfs. Change the Compiler to the new GCC entry we just created. Change Qt version to the Qt Versions entry we just created. Hit Apply.


That is the basic setup. If gdb is wanted, it has to be set up under Debuggers and Kits, similarly to the Compiler.

Now go to the Devices page in Options. Hit Add. Choose Generic Linux Device and start the wizard. Enter the IP address and ubuntu/ubuntu as username and password. Hit Next and Finish. The testing should succeed. There is no need to associate this Device with the Kit if there is only one Generic Linux Device, but it may become necessary once there are multiple devices configured.


Building and Deploying from Qt Creator

Let’s check out the Cinematic Experience demo sources: git clone In the Configure Project page, select only the kit just created. The configuration is Release since our Qt build was release only. Hit Configure Project. When creating a new project, the approach is the same: make sure the correct kit is selected.

Build the project. Creator will now correctly pick up the cross-compilation toolchain. The result is an ARM binary on our host PC. Let’s deploy and run it.

Choose Deploy. This will likely fail, watch the output in the Compile Output tab (Alt+4). This is because the installation settings are not yet specified in the .pro file. Check this under Run settings on the Projects page. The list in “Files to deploy” is likely empty. To fix this, edit and add the following lines at the end:

target.path = /home/ubuntu/qt/$$TARGET
INSTALLS += target

After this, our deployment settings will look a lot better:

Choose Run (or just hit Ctrl+R). Creator now uploads the application binary to the device and launches the application remotely. If necessary, the process can also be killed remotely by hitting the Stop button.

The host and the target

This means that from now on, when doing further changes or developing new applications, the changes can be tested on the device right away, with just a single click.

What’s Next

That’s all for now. There are other interesting areas, multimedia (accelerated video, camera), CUDA, and Vulkan in particular, which unfortunately do not fit in this single post but may get explored in the future. Another future topic is Yocto support and possibly a reference image in the Qt for Device Creation offering. Let us know what you think.

The post Qt on the NVIDIA Jetson TX1 – Device Creation Style appeared first on Qt Blog.

KDAB at ECS, Stockholm, Nov 22-23

KDAB exhibited at Embedded Conference Scandinavia in Stockholm – Nov 22-23.

Contact us if you met us at Stand 71 and saw our demos there.

On November 23rd at 16:15, KDAB’s Milian Wolff introduced attendees to perf, the Linux tool suite for performance analysis. His talk covered a broad part of what perf has to offer for user space developers. Afterwards, attendees knew how to use perf to find CPU hotspots in their code as well as some tricks to profile wait times for lock contention issues or disk I/O.

Linux perf is a tremendously powerful tool suite for performance analysis: It can do basically everything, from CPU sampling profiling to tracing of syscalls or even dynamic tracepoints in your own code.

While perf is powerful, it is also quite complex and hard to master. Currently, it consists of more than twenty tools, most of which often require custom configuration to get conclusive results. Thus, newcomers have a hard time overcoming the steep learning curve.

This talk aimed to shortcut this process by laying the foundation for any user-space developer to get started with Linux perf. The basic ways to profile CPU hotspots were covered and a dive into some more involved tricks to investigate lock contention or latency issues. Finally, an introduction to custom profiling and data evaluation with Python scripting was given.
About the presenter:
Milian WolffMilian Wolff is a Software Engineer at KDAB in Berlin. A long-term contributor to KDE, Milian’s passion for tooling leads him to be one of the most active contributors to KDevelop and Kate Tooling. He is also a Linux perf contributor. Milian is the creator of the Massif-Visualizer and more recently heaptrack tools, both designed to improve memory consumption in applications.

In addition to client work, Milian contributes to GammaRay, KDAB’s Qt runtime introspection tool, and delivers KDAB training in the art of debugging and profiling software with various tools. 

Contact us to find out more.

The post KDAB at ECS, Stockholm, Nov 22-23 appeared first on KDAB.

Meet Qt à Lyon – le 1er Décembre

Meet Qt à Lyon.

Rejoignez nos experts Qt pour une journée à Lyon, le 1er Décembre 2016.

gammaray-qq2-qsg-visualize2Nous serons à l’hôtel Novotel Lyon Part-Dieu avec The Qt Company et Witekio, pour répondre à vos questions et vous montrer quelques-unes de nos démos. Vous verrez GammaRay : l’outil graphique qui vous permet, entre autres, de visualiser l’état interne de Qt Quick et de Qt 3D, et Qt 3D avec Physically Based Rendering (PBR) qui vous permet de réaliser des animations 3D réalistes.

Obtenez de l’aide de nos experts pour démarrer efficacement sur ces sujets et bien plus encore.

Voir l’agenda complet ici.

Places limitées. Inscrivez-vous maintenant.

Adresse: Novotel Lyon Part-Dieu, 47 Boulevard Vivier Merle, CS 63513 Cedex 03, 69429 Lyon de 09h00 à 16h00.

The post Meet Qt à Lyon – le 1er Décembre appeared first on KDAB.

Qt 5.8 Beta Released

I am pleased to announce that Qt 5.8 Beta is now released. Containing all-new configuration system, new graphics architecture with integrated Qt Quick 2D Renderer for devices without OpenGL, build in QML cache for improved startup and many other new features, Qt 5.8 will be a very interesting release. I hope many will take the Qt 5.8 Beta release, test it and provide feedback for us to complete Qt 5.8. For the big picture of the release, see the alpha release blog post.

We have prepared convenient binary installers for the Qt 5.8 Beta, so it is easy to download, test and provide feedback. For any issues you may find with the Beta, please submit a detailed bug report to (after checking the known issues). You are also welcome to join the discussions in the Qt Project mailing lists, developer forums and of course to contribute to Qt.

To try out the new features you can download Qt 5.8 Beta from your Qt Account or from

The post Qt 5.8 Beta Released appeared first on Qt Blog.

Qt World Summit 2016 Webinar Series Kicks Off

November Qt World Summit Webinars

This month, be sure to catch our upcoming online events and register now:

Qt Quick Scene Graph Advancements in Qt 5.8 and Beyond
presented by Laszlo Agocs, Senior Software Engineer, Qt R&D

The Curse of Choice: An overview of GUI technologies in Qt?
presented by Andy Nichols, Senior Software Engineer, Qt R&D

Qt & IoT: Do they fit together?
presented by Alex Blasche, Senior Software Engineer, Qt R&D

Stay tuned for details on upcoming webinars for December!

All upcoming events from The Qt Company and its partners are available in our new community calendar at

The post Qt World Summit 2016 Webinar Series Kicks Off appeared first on Qt Blog.

CppCon Special Report

KDAB has long supported the C++ community, as C++ is the backbone of Qt and up-to-date knowledge of its changes keeps us on the leading edge in the Qt world.

Later this year we shall be supporting Europe’s Meeting C++ in Berlin, but now that this year’s talks have been released we felt it was time for a Special Report on CppCon which ran from September 17th-23rd this autumn in Bellevue, WA.

KDAB’s Kévin Ottens was on the program committee and reviewed the talks at this year’s show, while Giuseppe D’Angelo (Peppe) contributed a day’s training on Programming with Qt Widgets, and two Lightning Talks on Qt (see them here and here), as well as attending the rest of the event.

We asked Kévin and Peppe to list their top three talks so we could get the insider as well as the attendee perspective. This is what they gave us:

Kévin’s top three

1. C++ on the Web: Let’s have some serious fun (Video)

  • “Shows that C++ is very versatile and can be used even in the trendy web field unlike what most engineers assume.”

2. Iterator Haiku, Casey Carter (Video)

  • “Because iterators in general reduce opportunities of errors in your code, and it will become even better with the ranges.”

3. How to test static_assert? (Video)

  • “I love static_assert to catch mistakes and wrong assumptions even earlier in the development process, but I also want my code to be tested as much as possible. As the title implies, it’s a perfect match.”

Peppe’s top three

1. Lifetime Safety… By Default: Making Code Leak-Free by Construction (Video)

  • “It was the keynote by Herb Sutter. Great speaker and great content.”

2. What C++ Programmers Need to Know about Header <random> (Video)

  • “Because everyone has a program that needs a random integer between 1 and 42 and does it wrong. <random> does it right.”

3. My Little Optimizer: Undefined Behavior is Magic (Video)

  • “In case you were looking for arguments why you should never ever ever ever trigger undefined behavior: compilers see your bluffs and do terrible things.”

You can see Giuseppe’s blog post about CppCon here.

The post CppCon Special Report appeared first on KDAB.

Qt Creator 4.2 Beta released

We are happy to announce the release of Qt Creator 4.2 Beta.

Qt SCXML Editor

Flat Dark Theme - Qt Creator 4.1

Qt SCXML is a new module in Qt that allows you to create state machines from State Chart XML and embed them into Qt C++ and Qt Quick applications (Overview). It was released as Technical Preview in Qt 5.7 and will be released fully supported with Qt 5.8.

Qt Creator 4.2 now supplements the module by offering a graphical editor for SCXML (experimental). It features editing states and sub-states, transitions, events, and all kinds of properties. The editor is experimental and the plugin is not loaded by default. Turn it on in Help > About Plugins (Qt Creator > About Plugins on macOS) to try it.

Projects Mode

We reworked how you select the project and it’s diverse settings in Projects mode. Instead of nested tabs, you now select the project from a dropdown, and the settings that you want to edit from a tree that shows all available kits and other categories, making for a much cleaner UI. Enabling use of a kit for a project is now easily done by clicking the entry in the tree. Please provide feedback on any remaining issues through our bug tracker.

Qt Quick Designer

Qt Quick Designer has received many smaller features in this release. In the connections editor there is a new section for managing the imports and property definitions that are necessary for using C++ backend objects (documentation). Also support for padding (Qt Quick 2.6) was added, and you can now edit the when condition of states, and the diverse font properties of text items.

Other Additions and Improvements

When profiling your QML code you now have the option to show memory usage and allocations as flame graphs as well.

We added Tools > Diff > Diff Current File and Diff Open Files for showing a local diff of the modifications of files in Qt Creator with respect to their versions on disk.

Performance of opening CMake projects was improved, and support for predefined options for properties was added.

There were many more changes, which are described in more detail in our change log.

Get Qt Creator 4.2 Beta

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

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

Tuple And Pair in C++ APIs?

Quick: When you design C++ APIs, when and how should you use pair and tuple?

The answer is as simple as it is surprising: Never. Ever.

When we design APIs, we naturally strive for qualities such as readability, ease-of-use, and discoverability. Some C++ types are enablers in this regard: std::optional, std::variant, std::string_view/gsl::string_span, and, of course, std::unique_ptr. They help you design good interfaces by providing what we call vocabulary types. These types may be trivial to implement, but, just like STL algorithms, they provide a higher level of abstraction (a vocabulary) in which to reason about code. Unlike algorithms, though, which appear mostly in the implementation, and don’t affect APIs much, vocabulary types are at their best when used in APIs.

So, I asked myself, are std::pair and std::tuple vocabulary types?

Vocabulary Types

To answer the question, I looked at what these types help model. This should be trivial to answer for vocabulary types, much as it’s trivial to remember what an STL algorithm does just by looking at the name.

Take std::optional, for example. It models a value that may be absent, i.e. an optional value. This is great. When you start looking for uses, you can’t help but see lots of opportunities just jumping out at you: std::optional is the perfect value type for hash tables that use open addressing. The atoi() return value could finally distinguish between a zero and an error:

if (auto result = atoi(str))
    std::cout << "got " << *result << std::endl;
    std::cout << "failed to parse \"" << str << "\" as an integer: " << "???" << std::endl;

But what if you want to return an error code, or a human-readable error description? Then std::optional is not the prime choice. There should never be an error and a valid parsed value returned from the same invocation of atoi(), so something like std::variant seems perfect.

But is it?


auto result = atoi(str);
if (auto i = std::get_if<int>(&result))
    std::cout << "got " << i << std::endl;
else if (auto error = std::get_if<std::error_code>(&result)))
    std::cout << "failed to parse \"" << str << "\" as an integer: " << error.message() << std::endl;
    std::cout << "oops, variant was in invalid state" << std::endl;

Some people may call this good API, I call it horrible. If you force your users to query the result with a chain of get_ifs, then you are abusing std::variant, which is designed to contain alternative types with similar purpose, so that it can be efficiently handled using a static visitor. You could use a visitor to handle the result of atoi(), but is that really an API you’d want to work with?

A New Vocabulary Type

Put yourself into the position of the users of your API. What they want is a std::optional where the option is not between presence and absence of a value, but between a value and an error code. So, give it to them:

template <typename T>
class value_or_error {
    std::variant<T, std::error_code> m_v; // space-saving impl detail
    explicit value_or_error(std::error_code e)
        : m_v(std::move(e)) {}
    explicit value_or_error(T t)
        : m_v(std::move(t)) {}

    std::error_code error() const {
        if (auto e = std::get_if<std::error_code>(&m_v))
            return *e;
            return std::error_code();

    T& operator *() { return std::get<0>(m_v); }
    T const& operator *() const { return std::get<0>(m_v); }

    explicit operator bool() const { return !error(); }
    bool operator !() const { return error(); } 


if (auto result = atoi(str))
    std::cout << "got " << *result << std::endl;
    std::cout << "failed to parse \"" << str << "\" as an integer: " << result.error().message() << std::endl;

There, we just created a possible new vocabulary type.

But ok, I digress. Back to std::pair and std::tuple. What do they model?

As best as I can put it, a std::pair models a pair of two values, and std::tuple models a … tuple of zero to (insert your implementation limit here) values. Sounds simple, but what does that actually mean? Since std::pair is a subset of std::tuple, let’s restrict ourselves to just tuples.

We have a language construct, inherited from C (boo!), that allows us to package a pair or a triple or … of values into one object: it’s called struct. It doesn’t even have a limit on the arity of the object. Surprise!

Pair Models … Struct, Tuple Models … Struct

So, what’s the advantage of a tuple over a struct?

I have no idea! But I guess the answer is “none”.

Ok, so what’s the advantage of a struct over a tuple?

Where should I begin?

First, you get to choose names for the values. The std::set::insert() function could be as easy to use as

template <typename Iterator>
struct insert_result {
    Iterator iterator;
    bool inserted;
auto result = set.insert(obj);
if (!result.inserted)
    *result.iterator = obj;

Sadly, what we got is std::pair:

auto result = set.insert(obj);
if (!result.second) // or was it .first?! - I can never remember...
    *result.first = obj;

Second, you can enforce invariants amongst the data members by making them private and mediating access via member functions, as we did in the value_or_error example, where accessing the value when an error was set would throw an exception.

Third, you can add (convenience) methods to the struct, possibly making it a reusable component in its own right:

template <typename Iterator>
struct equal_range_result {
    Iterator first;
    Iterator last;

    friend auto begin(const equal_range_result &r) { return r.first; } 
    friend auto end(const equal_range_result &r) { return r.last; } 
for (auto && [key, value] : map.equal_range(obj))
   // ...

None of this is possible if you use std::pair or std::tuple in your APIs.

Variadic Woes

There’s just one problem with structs: they cannot be variadic (yet), and that’s when using tuples as API is somewhat acceptable, because we have nothing else at the moment. But there’s hardly a handful of such cases in the standard library, and most deal with implementing std::tuple in the first place (std::tie(), std::make_tuple(), std::forward_as_tuple(), …). About the only example that’s not in <tuple> is the zip() function that’s being discussed:

auto v1 = ...;
auto vN = ...;
for (auto &&e : zip(v1, ..., vN))
   // ...

And you need Structured Bindings to make that acceptable:

for (auto && [e1, ..., eN] : zip(v1, ..., vN))
   // ...


I hope I could convince you that using std::pair and std::tuple in APIs is a bad idea. Or, to say it in the style of Sean Parent: “No raw tuples.”

Defining a small class or struct is almost always the superior alternative. C++ currently lacks just one feature that would all but obsolete tuples: a way to define variadic structs. Maybe the static reflection work will yield that mechanism, maybe we need a different mechanism.

In any case, if you are not in that 0.01% of cases where you need variadic return values, then there’s already no reason to continue using tuples and pairs in APIs.

Since we’re a Qt shop, too, I’ll leave you with an example of how even Qt, which somewhat rightfully prides itself for its API design, can get this wrong:

// Qt 5:
typedef QPair<qreal, QColor> QGradientStop;
// Qt 6 (hopefully):
struct QGradientStop {
   qreal location;
   QColor colour;

About KDAB

KDAB is a consulting company offering a wide variety of expert services in Qt, C++ and 3D/OpenGL and providing training courses in:

KDAB believes that it is critical for our business to contribute to the Qt framework and C++ thinking, to keep pushing these technologies forward to ensure they remain competitive.

The post Tuple And Pair in C++ APIs? appeared first on KDAB.