foss-north speaker line-up

I am extremely pleased to have confirmed the entire speaker line-up for foss north 2017. This will be a really good year!

Trying to put together something like this is really hard – you want the best speakers, but you also want a mix of local and international, various technologies, various viewpoints and much, much more. For 2017 we will have open hardware and open software, KDE and Gnome, web and embedded, tech talks and processes, and so on.

The foss north conference is a great excuse to come visit Gothenburg in the spring. Apparently, Sweden’s wildest city!

WebGL streaming in a Raspberry PI Zero W

A week ago I received my Raspberry Pi Zero W to play a bit with some IoT device. The specs of this small device computer are the following:

  • 1GHz, single-core CPU
  • 512MB RAM
  • Mini HDMI and USB On-The-Go ports
  • Micro USB power
  • HAT-compatible 40-pin header
  • Composite video and reset headers
  • CSI camera connector

But the interesting part comes with the connectivity:

  • 802.11 b/g/n wireless LAN
  • Bluetooth 4.1
  • Bluetooth Low Energy (BLE)

And especially from one of the hidden features that allows one to use the device as a headless device and connect using SSH over USB adding the following line to config.txt:
And modifying the file cmdline.txt to add:

remember to create a file called ssh to enable SSH access to your Raspberry Pi. There are plenty tutorials over the Internet showing this! 😀

To build a Qt version for the device you can follow this guide.
In the following screen shot, we can see the calqlatr example running directly on the Raspberry Pi:


One of the use cases which comes to my mind using this device and this feature is being able to create portable presentations and show them on any computer without the need of installing new software.


For the presentation, I used the qml-presentation-system (link).

More use cases could be:

  • Application showcase.
  • Custom text editor for taking your notes everywhere.

Please comment if you have other ideas or use cases.

The post WebGL streaming in a Raspberry PI Zero W appeared first on Qt Blog.

Boosting performance with shader binary caching in Qt 5.9

Now that Qt 5.9 is getting closer, let’s take a look at a minor but immensely useful improvement to the basic OpenGL enablers that form the foundation of Qt Quick and the optional OpenGL-based rendering path of QPainter.

Those looking at the documentation snapshots for 5.9 may have already come across some new functions in the venerable QOpenGLShaderProgram. What is more, most internal usages in Qt have been switched over to the new API. What does this mean in practice?

As explained here, such shader programs will attempt to cache the program binaries on disk using GL_ARB_get_program_binary or the standard equivalents in OpenGL ES 3.0. When no support is provided by the driver, the behavior is equivalent to the non-cached case. The files are stored in the global or per-process cache location, whichever is writable. The result is a nice boost in performance when a program is created with the same shader sources next time.

How big is the improvement? It varies. Some drivers have already been doing some sort of caching for the past couple of years, while some others have similar features in the pipeline. However, the gains turn out to be quite significant in practice on devices that are out in the field right now:


Do not read too much into the actual numbers. What is important is the difference between Qt 5.8 and 5.9. Also, a simple Qt Quick or GL-backed QPainter scene will definitely not use 10 programs, but as complexity grows, with Qt Graphical Effects and custom ShaderEffect items entering the picture, getting similar improvements does not look far fetched anymore.

In fact we gain something even on systems that employ shader caching already. Therefore every application’s startup and view switching times are expected to benefit with Qt 5.9 – without having to change anything.

Applications that use QOpenGLShaderProgram on their own can usually switch to the cacheable function variants by just changing the name in the function call. The change have to be a conscious decision, though, since some of the APIs change semantics when program binaries are used. Most notably, QOpenGLShader, addShader(), and removeShader() are incompatible with the program-level caching since they rely on individual shader compilation.

That’s it for now, stay tuned for more posts about exciting upcoming Qt 5.9 and 5.10 features.

The post Boosting performance with shader binary caching in Qt 5.9 appeared first on Qt Blog.

Device Tailored Compositors with Qt Wayland at CLAAS E-Systems

by Andreas Cord-Landwehr [(PhD), Development Engineer at CLAAS E-Systems] (Qt Blog)

Software Development in Agriculture

Have you heard about software in cars that run on embedded devices? Do you think that creating such software might be challenging? Well, welcome to a complete new world of complexity, welcome to the world of agriculture machines! For many years, automatic steering (on fields), terminals to control the complex mechanical operations of a self-driving 16 ton combine harvester on a soft ground, and self-optimization systems to optimize any tiny bit of your harvester, are key demands from customers. I, myself, am working at CLAAS E-Systems, the electronics and software department within the CLAAS group. Our group is well known for being among the leading manufacturers for combine harvesters, tractors and forage harvesters.

The main human machine interaction interface on such machines, besides the driving joystick and the throttle pedal, are tablet like control terminals appended at the end of the driver’s arm rest. It is my daily job to bring awesome looking and user friendly interfaces together with safety regulations and put the results onto such terminals. Considering today’s demands on these terminals, we are approaching what one is used from a typical Linux desktop system: For example, one can think about different applications for steering, controlling the machine functionality, or the entertainment system. Such separations into different processes not only increase robustness. In a field with heavy safety regulations, clear separations of scopes and interactions they are a virtue to decrease effort spent on safety assurance.

Window Compositing using Wayland

Naturally, the composition of the different windows of separated processes into a seamless UI is the task of a window compositing system. From the desktop world we know the good old server that today is slowly replaced by much more modern Wayland compositors. In the mobile and embedded world its successor already took over and Wayland is the default choice when considering a window compositor. Unlike for, there are different implementations of the Wayland window compositing protocol. Best known, there is the Weston compositor, the actual reference implementation of the Wayland protocol. On top of it, driven by the demands in the automotive industry, there is also the IVI protocol abstraction layer. IVI provides a very small compositor interface with the primal goal of exchangeability and compatibility, for which your BSP (board support package) supplier usually has a compatible compositor to offer. And IVI often works well, specifically when you have a UI with only limited window dynamics or animations, like a static display of windows as it is the typical case for radio control and climate control windows in a car. But if you want to add fancy window animations or if you have a certain complex UI and gesture workflow in mind, the IVI protocol drastically shows its limits. Taking a step back and considering to extend the Weston compositor, however, would bring you into the complex world of working at the heart of one of your most crucial software components in an unfamiliar environment.

Qt Wayland Compositor

Recently with the Qt 5.8 release, the Qt Wayland Compositor Framework started to become a viable new alternative. It not only provides the Qt Quick API that allows you to easily create a compositor from scratch with just a few lines of declarative QML code. In particular, it allows you to change your work assumptions when thinking about a compositor: Since the whole compositor is created in Qt Quick and the complex surface interaction and Wayland protocol logic is well hidden, it is possible for “just” a Qt Quick developer with basic Wayland understanding to create a compositor from scratch. The big benefit therein lies in the point that such a developer is well trained in using Qt Quick for creating awesome user interactions with great looking UIs. For creating a compositor that presents all available windows in a swipeable way, a Qt Quick developer just uses a ListView, adds the windows and it’s done. Now think about how long a Wayland expert would need for this task and how challenging it would be to do some rapid prototyping for such a compositor in the other case.

The power of the QtWayland compositor framework thus is not only that it provides a nice and lean API to use but that it shifts the task of creating a Wayland compositor from the very specialized field of Wayland engineers to the field of Qt Quick/Qt developers. It allows you to focus just on creating the best interaction and UI for your customer, hence what really counts. If you are eager to try it out, just look at the examples shipped with the framework. Maybe you are also interested in my recent talk at FOSDEM ’17 in which I showed how simple it is to create a compositor from scratch.

The post Device Tailored Compositors with Qt Wayland at CLAAS E-Systems appeared first on Qt Blog.

QtMob: Qt mobile application development becomes easier

by Marco Piccolino [QtMob community manager] (Qt Blog)

As a professional mobile application developer you probably already know by now how awesome Qt makes most of your daily job.

Yet, things like finding that useful (but undocumented) qmake option, deciding upon the application architecture to use for your next project, implementing native extensions on Android and iOS, checking whether a suitable library for your component already exists, might prove quite difficult if you are on your own.

The forums, IRC and mailing lists are great places to start from for one-shot questions, but sometimes you need a dedicated environment with peers where you can have a more focused and ongoing discussion about your daily matters. Here is where QtMob comes in.

QtMob is a global community of professional Qt mobile application developers that are willing to share their pains, knowledge and resources.

QtMob is a Slack chat, so that you can leverage all the goodies that modern-day, computer-mediated conversation has to offer.

It is a tool that you can open in the morning while sipping your coffee/tea, to likely find a bunch of fresh new mobile-related resources that someone just posted.

It sports a good mix of professional Qt mobile app developers, relatively fresh Qt users who love being on the cutting edge and sharing what they just discovered, Qt veterans who are looking for a smooth transition to newer topics like mobile and Quick, members of the QtCompany who want a direct channel with a group of mobile devs for feedback, as well as professionals from companies which have invested in Qt on mobile to provide middleware and services to application developers.

Members come from industries as diverse as game development, medical software, geographic informations systems, you name it. That’s just as diverse as the Qt users spectrum.

QtMob is also a place for collaborations, where members get feedback about new packages and tools they are offering or plan to offer to the community (among others, Cutehacks’ qpm package manager, Qt Champion Benlau’s many utility libraries, Grecko’s SortFilterProxyModel qml wrapper, Esri’s ArcGIS SDK, VPlay’s mobile SDK or just recruit consultants for their next project.

QtMob is the right place to start an in-depth discussion about strategies to prevent memory warnings on iOS, choosing the right push notifications component, talking about Qt and Redux, implementing CI, making .pro changes to support your build, or just shouting your frustation in the #bottomlesspit channel.

Here are a few first impressions from a community member, Sassan from Teheran:

“After joining this group I was able to ask questions, and there was always someone who responded quickly, either with the solution or the reason why it was not possible yet to achieve what I needed. A question may initiate discussions about the topic, and you’ll end up knowing much more than what you asked for, which is good because it will save you lots of time not doing the wrong things others have tried before. Your question may end up as a feature request on the Qt bugtracker.

After joining this group I was able to know about the latest technologies, packages, related softwares, etc around Qt. It’s really nice to know for example the time you spend to release your app can be reduced 5 times by using tools people discuss about here… and that’s just an example.

After joining this group I had the chance to know about the latest up-to-date documents (pdfs, videos, tutorials, etc.) people create about coding in Qt.

After joining this group I had the chance to meet so many nice people, many of whom spend part of their time to contribute to this open source project.

After joining this group I learned about best practices for doing things I already knew how to do, but which I can now do better.”

We recently celebrated user #100 (while I write the count is 130), Jeff Galbraith from iMirror: a good example of using Qt for mobile in innovative settings like fitting rooms. But QtMob members use cases are just so many…

Come along and see, it’s free!

The only requirement: be willing to give at least as much as you get, in whatever form is best suited to your level of experience and job constraints.

The post QtMob: Qt mobile application development becomes easier appeared first on Qt Blog.

Swift and Google Summer of Code 2017

It’s Google Summer of Code time again! Swift is participating in GSOC2017 under the banner of the XMPP Standards Foundation and we’ve posted a range of project ideas covering Swift and Swiften on the XSF wiki. Read on for more information.

As reported in a post on the XMPP Standards Foundation blog, the XSF has once again been accepted as one of the Open Source organizations participating in Google Summer of Code.

We’ve listed some "potential ideas for Swift and Swiften GSOC projects on the XMPP Wiki so, if you’re interested in participating as a GSOC student this year, please take a look.

If any of these projects are of interest, or if you have ideas of your own you’d like to propose, then please join the chat room to discuss GSOC and ask questions. We’ve had some great experiences with previous GSOC projects and we’re very much looking forward to working with students this summer.

Cutelyst 1.5.0 released, I18N and HTTPS built-in

Cutelyst the C++/Qt web framework just got a new stable release.

Right after last release Matthias Fehring made another important contribution adding support for internationalization in Cutelyst, you can now have your Grantlee templates properly translated depending on user setting.

Then on IRC an user asked if Cutelyst-WSGI had HTTPS support, which it didn't, you could enable HTTPS (as I do) using NGINX in front of your application or using uwsgi, but of course having that build-in Cutelyst-WSGI is a lot more convenient especially since his use would be for embedded devices.

Cutelyst-WSGI also got support for --umask, --pidfile, --pidfile2 and --stop that will send a signal to stop the instance based on the pidfile provided, better documentation. Fixes for respawning and cheaping workers, and since I have it now on production of all my web applications FastCGI got some critical fixes.

The cutelyst command was updated to use WSGI library to work on Windows and OSX without requiring uwsgi, making development easier. got Cutelyst logo, and an updated CMlyst version, though the site still looks ugly... .

Download here: .

Have fun! .

QNanoPainter with Qt 5.8 (and QSGRenderNode)

QNanoPainter recently gained initial support for QSGRenderNode which is a new public class available starting from Qt 5.8. What this means is that instead of rendering through FBO using QQuickFramebufferObject so, OpenGL drawing is done directly into Qt Quick Scene Graph. And as a QQuickItem somewhere in the middle of scene, not just underlay/overlay for the scene which was already possible before Qt 5.8 using beforeRendering & afterRendering.

Below is a video running QNanoPainter tester app on MacBook Pro with 16 unique QQuickItems using QSGRenderNode mode:

So should you enable QNANO_USE_RENDERNODE with your custom QNanoPainter items?

  • There is a potential performance gain for not rendering through FBO. Especially if your UI contains many custom items and/or you resize items, QSGRenderNode may give more gains as FBO resizing can be costly.
  • However, based on my testing with few different Android devices the performance difference seems pretty small, just few percentages. Maybe with some less performant embedded platforms which are bad with FBOs there is a bigger difference.
  • With QQuickFramebufferObject, rendering is always clipped to FBO size, so item clip true/false property doesn’t have any effect. With QSGRenderNode such clipping doesn’t automatically happen, instead each item can freely paint anywhere outside its rect. Whether this is pros or cons is up to your use case, but good to note anyway.
  • With QSGRenderNode, standard QQuickItem features (position, rotation, clipping, scaling etc.) need to be implemented customly. QNanoPainter doesn’t (yet) fully support clipping of QML item tree so if you have several clip regions and/or rotate these items, clipping doesn’t necessarily behave as expected when using QNANO_USE_RENDERNODE.
  • When your item doesn’t need to be repainted, just re-rendered, it’s more performant to render the FBO. So if your items don’t change often it might be better not to enable QNANO_USE_RENDERNODE.

So with all above said, QNANO_USE_RENDERNODE is not currently enabled by default even when building with Qt 5.8. But that might change somewhere in future if gains seem worth it. For now please upgrade your QNanoPainter library and test how it works for you.

Just three days left…

The call for papers for foss-north 2017 ends on Sunday. That means that you only have three days to…

  • … get a chance to visit Gothenburg, Sweden, the most sociable city in the world!
  • … speak in front of a great audience of 220 people (if we sell all the tickets – get your’s here).
  • … listen to other awesome speakers. Right now we’ve confirmed Lydia Pintscher, Lennart Poettering, Knut Yrvin and Jos Poortvliet. (There will be more awesome speakers announced when the call for papers is over).

So what are you waiting for – submit your talk proposal and join us at foss-north 2017!

What do I do if a slot is not invoked?

All Qt developers have asked themselves at least once in their careers: “why isn’t my slot invoked?” (I’ve asked myself that question many, many times).

There are a number of reasons why a connection may fail to be properly set up, and ultimately cause our slot not to be invoked. This blog post is a practical series of checks to help you debug these sorts of issues.

0. Was the slot really not invoked?

First and foremost, are we really …

The post What do I do if a slot is not invoked? appeared first on KDAB.

Provisioning OpenStreetMap providers in QtLocation


This post is to provide some clarification on a behavioral change we had to introduce with Qt 5.6.2 to the QtLocation‘s OpenStreetMap plug-in. The related change seems to have generated some confusion, so here’s the full story.

The OSM plug-in used to work with hard-coded tile server URLs for the various map types offered therein. The tiles for the main (street) map type and the satellite map type, which are possibly the two most used maps, were previously sourced from In July 2016, MapQuest discontinued this service. As a result, all deployed QtLocation OSM plug-ins for the Qt versions up to 5.6.1 and 5.7.0 suddenly began to provide tiles without map content. Instead the tiles contained an invitation to visit the MapQuest website and buy some services as shown below.

MapQuest ceasing open access

The dreadful sight from the MapViewer prior to Qt5.6.2


Clearly not being able to afford another such situation, we decided to fix this by adding one level of indirection. Now the OSM plug-in will fetch, for each map type, a provider definition file hosted at The format of this file is fairly similar to what others solutions use (e.g. TileJSON), with small differences needed for our specific use case. The format is documented in this file (starting from line 195). This solution makes it possible to change the tile source for specific map types, if this becomes necessary again, without the need to upgrade Qt or to rebuild the application.

These providers can also be temporarily disabled on the server side, by setting the property Enabled to false. This might happen in cases like the above mentioned where the service delivers bogus tiles and a replacement hasn’t been found yet. The plug-in also ships with a hard-coded backup for connectivity reasons.

Unfortunately, at this stage we haven’t been able to find an open access satellite imagery provider that would provide sufficiently high resolution data. As a result, the OSM plug-ins initially still offers seven map types (the satellite map type is still there) but, at the present, they become six as soon as the map provider definition file for the satellite type is parsed since it currently contains Enabled = false.

The screenshots below demonstrate the difference:

Mapviewer before and after resolution

The MapViewer MapType menu before provider initialization (left) and after (right)

While this approach solves the encountered problem, it might be an undesirable behavior for some. Therefore, we added two options to disable this behavior. The first option is to set the plug-in parameter osm.mapping.providersrepository.disabled to true. This instructs the plug-in to not attempt any remote provider file fetching, but to just use the hard-coded values. Since this alone would bring the initial problem back, there is also another plug-in parameter that may come in handy. The osm.mapping.providersrepository.address can be used to override the default value of, for 5.6.2 and 5.7.1, and for 5.8.0 and later releases. Developers can point the plug-in to an alternative URL containing the provider definition files for street, satellite, cycle, transit, night-transit, terrain and hiking. Even local URLs starting with file:/// or qrc:/ are possible, which means that the provider definition files can be shipped with the application.

As a last note, please bear in mind that this solution is still not 100% fail safe. The mapping service is still offered by third parties with whom The Qt Company has no contractual relationship. If a robust solution is needed, using one of the commercial services that we support through one of the other shipped plug-ins should be considered.

The post Provisioning OpenStreetMap providers in QtLocation appeared first on Qt Blog.

Qt QML Performance improvements in Qt 5.8.0

Qt 5.8 benefited from significant performance efforts in Qt QML.  Some of us spent our entire time figuring out why things are slow and what could be done. This is a continued effort that pretty much started with the first Qt QML release and I don’t think will ever stop.  After a bit of deliberation we decided to make it a bit more obvious what kind of effort is ongoing. Due to this long standing effort we have accumulated a lot of performance tools and benchmarks from internal and external contributors. This enables us to put some hard figures to the general claim.

Startup Times

We compared general startup performance and ran graphical and non-graphical benchmarks for Qt 5.6.2 and Qt 5.8.0. As platforms we used Windows, Ubuntu, macOS and an iMX6 board (the only 32 bit architecture in the mix). The startup figures were taken for the following Qt configurations:

  • Qt 5.6.2
  • Qt 5.6.2 with commercial Qt Quick Compiler (qmlcompiler)
  • Qt 5.8.0 without QML caching
  • Qt 5.8.0 with QML caching (first startup)
  • Qt 5.8.0 with QML caching (subsequent starts too)

The last two configurations take into account that the cache is generated the first time an application is started and reused on subsequent runs. This assumes that the application does not change in between runs. The application under scrutiny was the Qt Quick Controls Gallery example. There is no particular reason for this selection other than that it is fairly large and has a lot of JavaScript in it. Here are the main take aways:

  • On macOS and Ubuntu, using caches gives the same results as using the qmlcompiler.
  • On iMX6, the caching is an actual improvement of 60% over the qmlcompiler.
  • On Windows, something other than the caching has regressed. Further checks resulted in QTBUG-59360.
  • The figures show the negative impact of initial cache generation (between 10% to 180%).

QML Benchmarks

While the startup figures above give a very detailed overview for a chosen application, it is likely to not match the next application. This is where more detailed benchmarks come in. The QML benchmarks can be categorized into two areas. The first category is related to QML binding performance (create, read & write different types of properties) and the second category measures graphical drawing performance. What can we see?

  • QML property reads and writes are on average 25% faster on desktop and 35% faster on iMX6
  • especially low end hardware benefits dis-proportionally from recent changes
  • some iMX6 tests have regressions. Looking at the code, in particular the use of C++11 atomics seems to have a bad influence (Qt 5.7 and later require a C++11 toolchain). A toolchain update might help.


We started these regular measurements in October and each round of improvements actually sparked new rounds as new issues appeared. It taught us that we have to run those tests more regularly or even automate them. For transparency purposes I attached a more detailed summary of the benchmarks results.

It is fair to say that there are still open issues which need further resolution (e.g. the startup performance on Windows or some of the discovered regressions in individual performance tests). Besides toolchain/compiler updates it clearly shows that more areas besides Qt QML need to be looked at.

To summarize we have a very broad improvement across the board in Qt 5.8.0 and the figures even validate some of our already ongoing plans such as shifting of the cache generation to compile time or improvements to the garbage collector. Stay tuned 😉

The post Qt QML Performance improvements in Qt 5.8.0 appeared first on Qt Blog.

foss-north 2017: Call for Papers

The Call for Papers for foss-north is open for another week (until the 12th). This gives you an opportunity to speak in front of a great crowd. Looking at the results from last year’s questionnaire, more than 90% are users of open source software and more than 50% are contributors. One thing that surprised me, is that more people actually contribute as a part of their profession than as hobbyists. Looking at the professional vs hobbyist proportions, 45% of the visitors stated that they had their ticket paid by their employer/school, while 42% paid them out of their own pocket.

The topic of the conference is free and open source – so anything related is much welcome.We do not even limit ourselves to software – hardware, patents, community and much more is also appreciated topics. Last year we had speakers talking about timing synchronization over vast networks, patent issues, working as a designer, linguistics and must more.

As always with these things, crowd dynamics means that me as an organizer has to work on my stress management abilities. Almost 30% of the tickets to last year’s event was sold in the last two days before the event. The same goes for Call for Papers – nobody registers a talk in good time before the deadline. So if you want to help an ageing developer keeping the pulse under control – submit your talk proposal now! ;-)

Release 2.10.1: V-Play Apps, TexturePacker & Qt 5.8 Improvements

V-Play 2.10.1 is now available as a free update to all V-Play developers. It improves the OpenGL shader implementation on macOS when using Texturepacker and makes V-Play more compatible with Qt 5.8!

The update includes a number of improvements for both app and game developers. The highlights include improved connectivity, accurate tablet detection and a more stable Qt Creator.

The update also includes a number of fixes for V-Play Apps components and resolves an issue with Spine animations on Windows Phone and Win RT platforms.

New V-Play developers can sign-up now and get the tool for free!

Update V-Play Now!

V-Play App & Game Improvements

Improved Connectivity

Get V-Play 2.10.1 now and you can detect the isOnline network connectivity state in your apps and games.

This property lets you quickly check to see whether your app or game is correctly connected to an internet connection.

The update also fixes a possible issue on iOS and macOS that blocked the network access of the application after turning Wifi off and on again.

Improved Tablet Detection

V-Play 2.10.1 updates the diameterinches calculation for GameWindow and App, which provides more accurate tablet detection. The threshold for setting tablet  to <true> also increases to 5.3. This prevents tablet layout detection on bigger phones like the iPhone 7 Plus.

Improved TexturePacker Integration & Spine Fix

TexturePacker lets you manage your game’s spritesheets in a simple way, while also improving your game’s performance. V-Play 2.10.1 resolves a shader issue that caused compilation to fail in previous versions.

You can see a tutorial on adding TexturePacker to your V-Play games here!

V-Play 2.10.1 also fixes OpenGL issues when using Spine on Windows Phone and Win RT platforms.


V-Play Game Network Improvements

The V-Play Game Network is a mobile-backend-as-a-service that adds leaderboards, achievements and high scores to your mobile games. V-Play 2.10.1 improves the service in the following ways:

  • The icons in VPlayGameNetworkView now display correctly when using the component in combination with other icon fonts.
  • WebStorage initializes and synchronizes the current state with V-Play Game Network at first app startup.

You can see more about the V-Play Game Network here!

V-Play 2.10.1 Fixes

Qt World Summit 2016 Conference App Fix for Linux

The tint color of used controls gets rendered correctly again, when running the Qt World Summit 2016 Conference App demo on Linux.


You can get the full source code for this app when you download V-Play. The Qt World Summit 2016 Conference app is an open-source app example that you can use as the basis for your own conference app.

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 itunes download button

More Fixes

InputDialog::inputTextSingleLine now correctly passes the entered text to the provided callback function.

V-Play 2.10.1 fixes NavigationStack transition and Page::leftBarItem usage when showing a split-view with leftColumnIndex greater zero.

For a full list of improvements and fixes to V-Play in this update, please check out our change log!

How to Update V-Play

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.10.1 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.10.1!

For a complete list of the changes to V-Play with this update, please check out our change log!

More Posts like This

20 Free & Secure Alternatives to the Parse Push Service


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

tutorials capture

21 Tips That Will Improve Your User Acquisition Strategy

User Acquisition

7 Useful Tips That Will Improve Your App Store Optimization

ASO tips

The post Release 2.10.1: V-Play Apps, TexturePacker & Qt 5.8 Improvements appeared first on V-Play Engine.

Qt Installer Framework 2.0.5 released

We’re happy to release Qt Installer Framework 2.0.5.

2.0.5 is a bug fix release, the full list of bug fixes can be found from Changelog.

Installer Framework binaries can be installed from online installer. Binaries can be also found together with sources in (open source), or in your Qt Account. The binaries are built with Qt 5.6.0, minimum Qt version required is Qt 5.5.0.

We will continue fixing bugs to 2.0 branch but we are also aiming for making 3.0 release from master branch. 3.0 version will include many nice new features which we will inform more detailed later.

The post Qt Installer Framework 2.0.5 released appeared first on Qt Blog.

New in Qt 5.8: meta-object support for namespaces

A small new feature that was added to Qt 5.8 is the ability for moc (Qt’s meta-object compiler) to extract meta-object information at the namespace level. This means, for instance, that you can have introspection support for enumerations defined in a namespace (not just in QObject subclasses, or classes tagged with Q_GADGET), and use such enumerations in QtScript, QtDBus and QML.

Introducing Q_NAMESPACE

The support for all of this involves a few new macros. The most important one is …

The post New in Qt 5.8: meta-object support for namespaces appeared first on KDAB.

Heaptrack v1.0.0 Release

I’m extremely happy to finally announce the first stable release of heaptrack, the FOSS heap memory profiler for C/C++ Linux applications. You can download the source tarball from the KDE mirrors:

Heaptrack is a fast heap memory profiler that runs on Linux. It allows you to track all heap memory allocations at run-time. Afterwards, the accompanying GUI tool can be used to find optimization opportunities in your code by analyzing the recorded profiling data. It allows you to:

  • Inspect

The post Heaptrack v1.0.0 Release appeared first on KDAB.

KDAB contributions to Qt 5.8

Qt 5.8 has just been released! Another great release of Qt, made possible by thousands of commits by over a hundred different contributors:

Commit percentages to Qt in the last 16 weeks, grouped by employer

And here we are again, with the usual showcase of the most outstanding contributions to Qt 5.8 developed by KDAB engineers.

In no particular order:

Qt 3D

Qt 3D continues to receive lots of improvements and bugfixes, thanks to the hard work of …

The post KDAB contributions to Qt 5.8 appeared first on KDAB.

GammaRay 2.7.0 Released

We have released version 2.7 of our Qt application introspection tool GammaRay. GammaRay allows you to observe the behavior and data structures of Qt code inside your program live at runtime.

Here are a few of the highlights of this release:

  • The new Qt 3D geometry inspector allows you to look at a wireframe rendering of entity geometries, as well as the raw OpenGL buffer data. Visualizations of normal vectors and backface culling help to identify common problems in geometry

The post GammaRay 2.7.0 Released appeared first on KDAB.

Slaying Latency with Linux Kernel Tracepoints

Knowing what tools are at your disposal when looking to make a program faster or keep it operating smoothly is critical to your success as a programmer. We recently solved a performance problem using Linux Kernel Tracepoints so we thought we’d share the process with you so that you can see for yourself if this tool makes sense in your toolkit.

Our challenge: the database writes in a customer’s application normally took under 5ms but occasionally spiked to over 150ms, …

The post Slaying Latency with Linux Kernel Tracepoints appeared first on KDAB.

New and improved Inqlude web site

During last year's Summer of Code I had the honor of mentoring Nanduni Indeewaree Nimalsiri. She worked on Inqlude, the comprehensive archive of third party Qt libraries, improving the tooling to create a better structured web site with additional features such as categorization by topic. She did an excellent job with it and all of her code ended up on the master branch. But we hadn't yet made the switch to change the default layout of the web site to fully take advantage of all her work. As part of SUSE's 15th Hack Week, which is taking place this week, I took some time to change that, put up some finishing touches, and switch the Inqlude web site to the new layout. So here we are. I proudly present the new improved home page of Inqlude.

All libraries have additional meta data now to group them by a number of curated topics. You can see the topics in the navigation bar on the left and use them to navigate Inqlude by categories. The listing shows more information on first view, such as the supported platforms, to make it easier to find libraries according to your criteria without having to navigate between different pages. The presentation in general is cleaner now, and some usability testing has shown that the page works better now than before. In addition to the visible changes, Nanduni has also done quite a bit of improvements under the hood, including better automated testing. I'm proud of what we have achieved there.

It always has been a privilege for me to act as mentor as part of Google's Summer of Code or other programs. This is one of the most rewarding parts of working in free software communities, to see how new people learn and grow, especially if they decide to stay involved after the program has ended and become valuable members of the community for the long term. Being able to help with that I feel is one of the most satisfying investments of your time in the community.

Building the latest greatest for Android AArch64 (with Vulkan teaser)

Let’s say you got a 64-bit ARM device running Android. For instance, the Tegra X1-based NVIDIA Shield TV. Now, let’s say you are also interested in the latest greatest content from the dev branch, for example to try out some upcoming Vulkan enablers from here and here, and want to see all this running on the big screen with Android TV. How do we get Qt, or at least the basic modules like QtGui, QtQuick, etc. up and running on there?

nv_shield_2017 Our test device.

In this little guide we are going to build qtbase for Android targeting AArch64 and will deploy some examples to the Android TV device. To make it more interesting, we will do this from Windows.


The Qt documentation and wiki pages document the process fairly well. One thing to note is that a sufficient MinGW toolchain is easily obtainable by installing the official 32-bit MinGW package from Qt 5.8. Visual Studio is not sufficient as of today.

Once MinGW, Perl, git, Java, Ant, the Android SDK, and the 32-bit Android NDK are installed, open a Qt MinGW command prompt and set some environment variables:

set PATH=c:\android\tools;c:\android\platform-tools;
  C:\Program Files\Java\jdk1.8.0_121\bin;
set ANDROID_API_VERSION=android-24
set ANDROID_SDK_ROOT=c:\android

Adapt the paths as necessary. Here we assume that the Android SDK is in c:\android, the NDK in android-ndk-r13b, qtbase/dev is checked out to c:\android\qtbase, etc.

The Shield TV has Android 7.0 and the API level is 24. This is great for trying out Vulkan in particular since the level 24 NDK comes with the Vulkan headers, unlike level 23.

Build qtbase

Now the fun part: configure. Note that architecture.

configure -developer-build -release -platform win32-g++
  -xplatform android-g++ -android-arch arm64-v8a
  -android-ndk c:/android/android-ndk-r13b -android-sdk c:/android
  -android-ndk-host windows -android-ndk-platform android-24
  -android-toolchain-version 4.9 -opensource -confirm-license
  -nomake tests -nomake examples -v

Once this succeeds, check the output to see if the necessary features (Vulkan in this case) are enabled.

Then build with mingw32-make -j8 or similar.


To get androiddeployqt, check out the qttools repo, go to src/androiddeployqt and do qmake and mingw32-make. The result is a host (x86) build of the tool in qtbase/bin.

For general information on androiddeployqt usage, check the documentation.

Here we will also rely on Ant. This means that Ant must either be in the PATH, as shown above, or the location must be provided to androiddeployqt via the –ant parameter.

Now, Qt 5.8.0 and earlier have a small issue with AArch64 Android deployments. Therefore, grab the patch from Gerrit and apply on top of your qtbase tree if it is not there already. (it may or may not have made its way to the dev branch via merges yet)

After this one can simply go to a Qt application, for instance qtbase/examples/opengl/qopenglwidget and do:

mingw32-make install INSTALL_ROOT=bld
androiddeployqt --output bld
adb install -r bld/bin/QtApp-debug.apk


Now that a Qt application is installed, let’s launch it.

Except that it does not show up in the Android TV launcher.

One easy workaround could be to adb shell and do something like the following:

am start -n org.qtproject.example.qopenglwidget/

Then again, it would be nice to get something like this:


Therefore, let’s edit bld/AndroidManifest.xml:

  <action android:name="android.intent.action.MAIN"/>
  <!--<category android:name="android.intent.category.LAUNCHER"/>-->
  <category android:name="android.intent.category.LEANBACK_LAUNCHER" />

and reinstall by running ant debug install. Changing the category name does the trick.

Note that rerunning androiddeployqt overwrites the manifest file. A more reusable alternative would be to make a copy of the template, change it, and use ANDROID_PACKAGE_SOURCE_DIR.

The result

Widget applications, including OpenGL, run fairly well:


Or something more exciting:


No, really. That clear to green is actually done via Vulkan.


And finally, the hellovulkantexture example using QVulkanWindow! (yeah, colors are a bit bad on these photos)

adb logcat is your friend, as usual. Let’s get some proof that our textured quad is indeed drawn via Vulkan:

qt.vulkan: Vulkan init (         
vulkan  : searching for layers in '/data/app/org.qtproject.example.hellovulkantexture-2/lib/arm64'     
qt.vulkan: Supported Vulkan instance layers: QVector()              
qt.vulkan: Supported Vulkan instance extensions: QVector(QVulkanExtension("VK_KHR_surface" 25), QVulkanExtension("VK_KHR_android_surface" 6), QVulkanExtension("VK_EXT_debug_report" 2))    
qt.vulkan: Enabling Vulkan instance layers: ()                                                                                            
qt.vulkan: Enabling Vulkan instance extensions: ("VK_EXT_debug_report", "VK_KHR_surface", "VK_KHR_android_surface")                     
qt.vulkan: QVulkanWindow init                                                                                                        
qt.vulkan: 1 physical devices                                                                                                              
qt.vulkan: Physical device [0]: name 'NVIDIA Tegra X1' version 361.0.0                                                                     
qt.vulkan: Using physical device [0]                                                                                                      
qt.vulkan: queue family 0: flags=0xf count=16                                                                                                               
qt.vulkan: Supported device layers: QVector()                                                                                      
qt.vulkan: Enabling device layers: QVector()                                                                                       
qt.vulkan: Supported device extensions: QVector(QVulkanExtension("VK_KHR_swapchain" 68), QVulkanExtension("VK_KHR_sampler_mirror_clamp_to_edge" 1), QVulkanExtension("VK_NV_dedicated_allocation" 1), QVulkanExtension("VK_NV_glsl_shader" 1))                                                                                
qt.vulkan: Enabling device extensions: QVector(VK_KHR_swapchain)                                                     
qt.vulkan: memtype 0: flags=0x1                                                 
qt.vulkan: memtype 1: flags=0x1                           
qt.vulkan: memtype 2: flags=0x7                             
qt.vulkan: memtype 3: flags=0xb                               
qt.vulkan: Picked memtype 2 for host visible memory             
qt.vulkan: Picked memtype 0 for device local memory     
uniform buffer offset alignment is 256        
qt.vulkan: Creating new swap chain of 2 buffers, size 1920x1080       
qt.vulkan: Actual swap chain buffer count: 2                
qt.vulkan: Allocating 8847360 bytes for depth-stencil        

Should you need validation layers, follow the instructions from the Android Vulkan docs and rebuild and redeploy the package after copying the libVkLayer* to the right location.

That’s all for now. Have fun experimenting. The basic Vulkan enablers, including QVulkanWindow are currently scheduled for Qt 5.10, with support for Windows, Linux/X11, and Android. (the list may grow later on)

The post Building the latest greatest for Android AArch64 (with Vulkan teaser) appeared first on Qt Blog.

foss-north 2017

After much preparation, the tickets for foss-north 2017 is available at – grab them while they are hot!

The call for papers is still open (do you want to talk – register!) so we do not have a final schedule, but you will find our confirmed speakers on the web site as we grow the list. Right now, we know that have the pleasure to introduce:

  • Lydia Pintscher, the product manager of Wikidata, Wikimedia’s knowledge base, as well as the president of KDE e.V.
  • Lennart Poettering, from Red Hat known for systemd, PulseAudio, Avahi and more.
  • Jos Poortvliet, with a background from SUSE and KDE, he now heads marketing at Nextcloud.

The conference covering both software and hardware from the technical perspective. The event is held on April 26 in central Gothenburg located between Copenhagen, Oslo and Stockholm with an international airport.

This is a great excuse to visit a really nice part of Sweden while attending a nice conference – welcome!

Qt 5.9 Alpha Released

I am happy to inform you that Qt 5.9 Alpha has been released today.

Qt 5.9 Alpha is an important milestone on our way to the final Qt 5.9.0 release, which is targeted to be released by the end of May 2017.

The Alpha release is available only as source packages. Binary installers will be available via the online installer in conjunction with the Beta release as well as development snapshots during the coming weeks.

To learn about the features in Qt 5.9, please read the Qt 5.9 new features page. For more detailed overview of some Qt 5.9 key features, check the Qt Roadmap for 2017 blog post.

If you want to try Qt 5.9, please download the Qt 5.9 Alpha source packages from your Qt Account or from

Please remember to give us feedback by writing to the mailing lists and reporting bugs.

The post Qt 5.9 Alpha Released appeared first on Qt Blog.

Qt Quick WebGL Streaming

WebGL Streaming is optimized for Qt Quick and allows you to run remote Qt Quick applications in a browser.

I’m working on a platform plugin to run remote applications in your browser, using OpenGL command streaming.

When the remote application runs using this new platform plugin, the application will create a lightweight web server. When a user connects to the application, a web socket connection is opened between the server and the client, using QWebSocketServer.
The application running on a remote computer will serialize all GL calls to binary data and sends it using the web socket connection.

The local browser will send the event (mouse, touch or keyboard) to the remote application, so user interaction is allowed. Even multi-touch support! (up to 6 fingers):

And some Qt Quick demos running in the browser:

The “calqlatr” example:

“clocks” example:

“emitters” (particles) example:

“samegame” example:

Desktop browsers are also supported:

It allows multiple connections to the same application.


New windows are shown in a different canvas in the browser.screenshot_20170222_184419

To improve the performance, I’m also working to support web sockets compression. To be able to use the permessage-deflate extension. It’s actually working but needs more testing.

This feature is going to be introduced in Qt 5.10 as appears in the 2017 roadmap.

The post Qt Quick WebGL Streaming appeared first on Qt Blog.

Qt Roadmap for 2017

With Qt 5.7 and 5.8 released we have a completely new baseline for Qt 5 based applications and devices. In this blog, I want to provide a roadmap update on what we are currently working on in the Qt R&D and what the future directions are.

About a year ago I provided a roadmap update for 2016. Looking back the past year, I am very happy and proud that we have been able to develop and deliver all those great features and improvements. I would like to thank each and every Qt developer for their input. While most of the functionality is created by The Qt Company, we also have many community contributors who have provided multiple extremely valuable contributions throughout the years. In addition to those contributing code, we have also a large number of people active in the Qt Project forums, on mailing lists, as well as reviewing code and testing the Qt development releases. Together we create the Qt framework. Thanks!

Release Timelines

Throughout the lifetime of Qt 5 we have been steadily providing a new feature release of Qt every six months. While it has taken a bit longer than anticipated to release some versions, we have been able to keep this heartbeat steadily. Our plan is to continue to do so in the future. Therefore, after Qt 5.8 we will release Qt 5.9, Qt 5.10 and Qt 5.11 with roughly six month intervals.

Despite Qt 5.8 just being released, we already have the features of Qt 5.9 frozen and the alpha release will be available very soon. For those interested in taking a closer look into Qt 5.9 features, please check out the New Features of Qt 5.9 wiki page. Our target is to release Qt 5.9 in May 2017. Parallel to finalization of Qt 5.9, the development of Qt 5.10 is ongoing. Everything that is merged now to the dev branch of Qt is to become part of the Qt 5.10 release planned for November 2017. After Qt 5.10 is branched from dev, development of Qt 5.11 starts with planned release in May 2018.

New Features in Qt 5.9

Qt 3D was first released with Qt 5.7 and in Qt 5.8 the focus was mostly on stability and performance. With Qt 5.9 we are providing many new features which significantly improve the functionality of Qt 3D. Notable new features include support for mesh morphing and keyframe animations, using Qt Quick items as a texture for 3D elements, as well as support for physically based rendering and particles. There are also multiple smaller features and improvements throughout the Qt 3D module.

We are continuously focusing into improving graphics performance and Qt 5.9 brings new graphics features focusing especially on performance optimization. Applications utilizing OpenGL shaders will benefit from new shader disk cache, which will significantly reduce the initialization time of OpenGL shaders. With our measurements we have seen up to 10x improvement in shader performance compared to Qt 5.6 and up to 8x improvement compared to Qt 5.8 in some commonly used embedded devices. Other graphics related improvements in Qt 5.9 include sharing of resources such as bitmaps between processes reducing memory consumption in multiprocess systems, support for Wayland XDG Shell version 6 and support for Wayland IVI extensions.

On the QML engine side we introduced a major new approach with Qt 5.8: a disk cache for the just-in-time compiled QML and JavaScript. The work will continue towards introducing a completely re-implemented Qt Quick Compiler for ahead-of-time compilation of QML and JavaScript. Qt 5.9 offers the commercial-only ahead-of-time compilation with Qt Quick Compiler and the binary cache for just-in-time compiled QML to commercial and open-source users, just like Qt 5.8. In addition, Qt 5.9 provides a preview of a new ahead-of-time cache generation, which we aim to develop further for the Qt 5.10 release. The new approach is intended to replace the earlier Qt Quick Compiler with similar or improved performance on all supported platforms. For Qt 5.9, we are providing also some further improvements in the QML engine. Most notably the completely rewritten garbage collector offers a base line for improved speed and reduced memory consumption of future Qt Quick applications.

We have further tuned Qt Quick Controls functionality and added many new features improving the usage across desktop, mobile and embedded platforms. With Qt 5.9 we are adding ScrollView, an editable ComboBox and multi-touch support, to name a few of the most interesting new features. The new ScrollView provides flicking and non-interactive scroll indicators on touch and switches to interactive scroll bars when interacted with a mouse pointer. The editable ComboBox allows typing in auto-completed values using keyboard and multi-touch support allows interacting with multiple buttons and sliders at the same time.

Qt Network and especially QNetworkAccessManager (QNAM) have been improved in Qt 5.9. Previously, the behavior when encountering an HTTP redirect had to be defined per HTTP request by setting an attribute. Now there is also a new redirect policy that can be set globally in QNAM. If redirect behavior is to be specified in multiple ways, the first priority is defined per request with a policy, the second is per request with an attribute and finally the global QNAM policy takes control. Another major improvement is the HTTP Strict Transport Security (HSTS) support. HSTS is a web security policy, described in RFC6797, that allows a web server to declare that user agents should only interact with it using secure HTTPS connections.

We have some platform specific improvements as well as support for new platforms and compilers coming with Qt 5.9. Especially macOS is receiving many improvements, as we are updating the macOS platform plugin in order to support modern and future features of the operating system, especially on the graphics side. For Windows users, Qt 5.9 targets to bring support for the new VS2017 compiler. We may also be offering pre-built binaries for VS2017 with Qt 5.9 (depending on when VS2017 is released). With Qt 5.9 we are re-introducing support for INTEGRITY allowing creation of safety critical systems with Qt on top of the INTEGRITY RTOS.

These are examples of some of the new things coming with Qt 5.9, for full list of features please check

Directions for Qt 5.10 and Beyond

After the branching of Qt 5.9 the dev branch now contains what will become Qt 5.10. It is planned to be released in November 2017 and its development has already started. We are currently finalizing the development priorities and here are some items we have been considering to do for Qt 5.10.

Qt is very widely used with over one million developers and a vibrant ecosystem. Sometimes a user just starting with Qt may find it a bit challenging to get going. One reason for this challenge is the fact that Qt is so versatile – we often offer multiple ways of developing applications. Sometimes it may also happen that parts of our documentation and examples are slightly outdated or do not clearly highlight what is the best approach for the user. While the work with documentation and examples is a constant effort, with Qt 5.10 we are planning to have a further push to improve the experience of getting started with development of Qt application and devices.

Running Qt applications in a browser via Native Client (NaCl) has been possible since 2009 and since Qt 5.8 VNC can be used for remote control of Qt applications. However these options are often not as convenient as desired. With Qt 5.10 we are planning to support streaming of Qt Quick application UIs over a network to a browser using WebGL. This streaming of OpenGL commands will allow using a common browser as a remote display of a Qt application running e.g. in a nearby embedded system or far across a network. Input from touch/mouse as well as keyboard is transmitted back to the Qt application. WebGL streaming will be implemented as a platform plugin in Qt 5.10. The streaming plugin converts all painting commands to WebGL commands and transmits the streams to clients. In turn those clients transmit user input back. Clients can be Qt applications or any web browser capable of showing WebGL 1.0.

On the graphics domain we are working with some nice additions targeting Qt 5.10. The first one being support for arbitrary path rendering (i.e. shapes) in Qt Quick. This allows declaratively specifying complex shapes built from lines, curves and arcs directly in QML and rendering them in an accelerated manner. Continuing on the approach started with the scenegraph modularization in Qt 5.8, the solution is expected to have multiple backends internally. For instance, NVIDIA-based systems will be able to utilize the GL_NV_path_rendering OpenGL extension transparently to the applications. The second new item is to provide basic Vulkan enablers in Qt. These allow creating Vulkan-capable windows and integrating code performing rendering with Vulkan into Qt C++ applications on multiple platforms, while abstracting and hiding the platform and windowing system specific bits. The third item we are researching is to use modern OpenGL features in Qt. Especially those offered by OpenGL ES 3.2 are quite interesting to improve the Qt Quick scenegraph performance and to potentially introduce new features like e.g. built-in support for compressed textures.

In the 3D area, we recently received a major contribution from NVIDIA, who contributed their complete 3D UI development tooling to Qt. During the coming year we will develop the tooling and its Qt integration further to enable smooth creation of 3D UIs for Qt applications. We will improve the existing integration into Qt and introduce more Qt functionality within the tooling itself. In the long term, we are also aiming to port the tooling to fully leverage Qt to support Mac and Linux hosts for development (initially the tool is for Windows only). For deployment the tool will support all desktop, embedded and mobile platforms generally supported by Qt. To check out what is already possible with the tool, please read the the recent announcement blog post for Qt 3D Studio.

Patch Releases and Long-Term Support

In addition to feature releases we make patch releases providing improvements to functionality introduced in those new feature releases. The primary purpose of a patch release is to provide a collection of bug fixes to issues found in the .0 feature release. Typically, the first patch release contains many fixes which were already completed at the time of the .0 release, but were not considered critical. The bug fixes done after the .0 release will end up in the next patch level release, as well as merged up to the next feature release.

Unfortunately, we have not been as efficient in providing the patch releases as we would like to. For Qt 5.7 we only created one patch release in December, almost 6 months after the Qt 5.7.0 release. We are currently renewing the CI system infrastructure, which will increase the capacity of the Qt CI system and allows us to make more patch releases from Qt 5.9 onwards. Unless there are significant security or other issues found, we are not planning to provide any patch releases for Qt 5.8 to make sure that we release Qt 5.9.0 with the planned schedule. Qt Support will assist customers to overcome possible issues found in Qt 5.8.0 release.

For Qt 5.6 LTS we have already provided two patch level releases adding quite a lot of improvements. Going forward we will make less changes to the Qt 5.6 LTS version. Since Q4/2016 we have already reduced the number of fixes going into the 5.6 branch. While each fix as such is beneficial, they are also possible risks for behavior changes and regressions, which we want to avoid in LTS releases. Next patch release, Qt 5.6.3 LTS, is planned to contain only fixes for critical bugs and security issues. The planned timing of Qt 5.6.3 is after Qt 5.9 has been released.

We are considering possibilities to extend support of Qt 5.9. The decision has not yet been made whether it should be a generic LTS or something that is provided only for selected platforms (e.g. embedded only). In any case we intend to create more patch releases for it than we have been able to do for Qt 5.7 and 5.8. The ongoing improvements and increasing the capacity of our CI system will help achieve this.

Get involved

During the coming months we will be hosting several webinars about key features in Qt 5.8. There will also be many blog posts about the new innovations in Qt targeting Qt 5.9 and Qt 5.10. If you want to learn more about Qt, please contact our sales teams or join the discussion in the Qt mailing lists and developer forums. We are always delighted to see new contributors in the Qt Project as well as feedback to the pre-releases of Qt via bugreports.

If you are interested in working with us to shape the future of Qt, we have many open positions at The Qt Company.

The post Qt Roadmap for 2017 appeared first on Qt Blog.

Making Movies with QML

by Andy Nichols (nezticle) (Qt Blog)

One of the interesting things about working with Qt is seeing all the unexpected ways our users use the APIs we create.  Last year I got a bug report requesting an API to set a custom frame rate for QML animations when using QQuickRenderControl.  The reason was that the user was using QQuickRenderControl as an engine to render video output from Qt Quick, and if your target was say 24 frames per second, the animations were not smooth because of how the default animation driver behaves.  So inspired by this use case I decided to take a stab at creating such an example myself.


This may not be the most professional looking User Interface, but what it does is still pretty neat.  The objective is to feed it an animated QML scene and it should output an image file for each frame of the animation.  These images can then be converted into a video or animated image using an external tool.  The challenge is that Qt Quick is a UI tool, not a movie generator.

The naive approach to this would be to create a QQuickWindow, set the window size to the output target size, and then grab the frame by calling QQuickWindow::grabWindow() each time the frameSwapped() signal is emitted.  There are a couple of issues with this approach though.  First is that the video would need to render in realtime.  If you wanted to render an animation that was 5 minutes long, it would take 5 minutes because it would just be like recording your application for 5 minutes.  The second issue is that under the best case scenario you would be rendering video at the refresh rate of your monitor. This would even require a reasonably powerful machine, because the QQuickWindow::grabWindow() call involves a glReadPixels call which is quite expensive.  It is also problematic if you need to render at a different frame rate than your monitor refresh (which is what the user that inspired me was complaining about).  So here is how I addressed both of these issues.


QQuickRenderControl is a magical class that lets you do all kinds of crazy things with Qt Quick content.  For our purposes we will use it to render Qt Quick content to an offscreen surface as fast as we can.  Rather than creating an on-screen QQuickWindow, we can create a dummy QQuickWindow and via render control we can render content to an QOpenGLFramebufferObject instead.

    // Setup Format
    QSurfaceFormat format;

    // Setup OpenGL Context
    m_context = new QOpenGLContext;

    // Setup dummy Surface (to create FBO with)
    m_offscreenSurface = new QOffscreenSurface;

    // Setup Render Control and dummy window 
    m_renderControl = new QQuickRenderControl(this);
    m_quickWindow = new QQuickWindow(m_renderControl);

    // Setup QML Engine
    m_qmlEngine = new QQmlEngine;
    if (!m_qmlEngine->incubationController())

    // Finish it all off

The above gets QQuickRenderControl setup, then when the size is know and you can actually create the QOpenGLFramebuffer object and tell the dummy QQuickWindow thats where it will be rendering.

void MovieRenderer::createFbo()
    m_fbo = new QOpenGLFramebufferObject(m_size * m_dpr, QOpenGLFramebufferObject::CombinedDepthStencil);

And once that is done it’s just a matter of loading up the QML content and rendering it.  Unlike with QQuickWindow, QQuickRenderControl allows you to control when the steps of the rendering process occurs.  In our case we want to render as fast as possible so this is what our rendering setup looks like:

void MovieRenderer::renderNext()

    // Polish, synchronize and render the next frame (into our fbo).

    // Grab the contents of the FBO here ...

    if (m_currentFrame < m_frames) { 
        // Schedule the next update 
        QEvent *updateRequest = new QEvent(QEvent::UpdateRequest); 
        QCoreApplication::postEvent(this, updateRequest);
    } else { 
        //Finished cleanup();
bool MovieRenderer::event(QEvent *event) { 
    if (event->type() == QEvent::UpdateRequest) {
        return true;
    return QObject::event(event);

The above sets up an event driven loop that will render as fast as possible while still handling events between frames, which is needed for progressing animations with Qt Quick.

Custom QAnimationDriver

The second issue we need to address is that the animation behavior is wrong.  To remedy this we need a custom QAnimationDriver that enables us to advance animations at our own frame rate.  The default behavior is to try and advance the animation’s in steps as close as possible to the refresh rate of the monitor your application is running on.  Since we never present the content we render to the screen that behavior doesn’t make sense for us.  Instead we can install our own QAnimationDriver which can be manually advanced each frame we generate based on a pre-determined frame rate.  Here is the whole implementation of my custom Animation driver:

class AnimationDriver : public QAnimationDriver
    AnimationDriver(int msPerStep)
        : m_step(msPerStep)
        , m_elapsed(0)

    void advance() override
        m_elapsed += m_step;
    qint64 elapsed() const override
        return m_elapsed;
    int m_step;
    qint64 m_elapsed;

Now to use this you just need to install the new QAnimationDriver.  When you call QAnimationDriver::install() it will replace the current one, so Qt Quick will then behave like we need it to.  When we start the movie renderer we also install the custom AnimationDriver:

    m_frames = m_duration / 1000 * m_fps;
    m_animationDriver = new AnimationDriver(1000 / m_fps);

    // Start the renderer

And finally since we control the render loop, we need to manually advance the animation driver.  So before the end of the renderNext() method make sure to call:


And that is it.  Now we can render as fast as possible, and our animation engine will step perfectly for the frame rate we are generate frames for.  It is important to remember that you must process events after calling advance() on your animations though, because these are handled through the Qt Event and Signal and Slots system.  If you don’t do this, then you will generate the same frame many times.


Once you run the MovieRenderer you end up with a folder full of images representing each frame.  To prepare video files from the generated output I used ffmpeg:

ffmpeg -r 24 -f image2 -s 1280x720 -i output_%d.jpg -vcodec libx264 -crf 25 -pix_fmt yuv420p hello_world_24.mp4

In the above command it will generate a 720p video at 24 fps from a series of files called output_*.jpg.  It would also be possible to create an example that either called this tool for you via QProcess, or even included an encoder library to generate the video directly.  I went for the simplest approach using only what Qt had built-in for this example.  Here are a few example movies I generated:

This first video is rendered at 60 FPS and the second is at 24 FPS.  Notice how they animate at the same speed but one is smoother than the other.  This is the intended behavior in action.

Well thats all I have to show, the rest is up to you.  I’ve published the code for the QML Movie Renderer here so go check it out now!  I hope this example inspires you as well to make other cool projects, and I look forward to seeing what new unexpected ways you’ll be using Qt in the future.

The post Making Movies with QML appeared first on Qt Blog.