Release 2.12.0: Qt 5.9 & Qt Creator 4.3 Support

V-Play 2.12.0 adds support for Qt 5.9 and the latest Qt Creator 4.3. Qt 5.9 adds many great features like support for gamepads and 3D key frame animations. Qt Creator 4.3 adds a much improved design mode, which allows you to write QML code side-by-side with a visual representation of the code. This allows rapid prototyping of UIs.

V-Play 2.12.0 Improvements

V-Play is now compatible with Qt 5.9 and Qt Creator 4.3, which adds an improved QML Designer. The biggest benefit of the new QML Designer is the new live preview of your QML code. You can have your UI side-by-side with QML code, which allows to further accelerate the development process.

Qt Quick Designer Side by Side Visual and Code

Some of the V-Play components now also support the QML Designer and visual development. The supported components include GameWindow, App, Scene, Page, NavigationStack and also most of the other components are working. With this improvement, you can now adjust component properties with a nice visual editor.

Other improvements of this V-Play release:

  • You can use an improved icon-font handling within games and apps and use the latest FontAwesome version 4.7.0 with the IconType component.
  • The Friends View now has an improved UI. You can use the V-Play friends system within V-Play Multiplayer to allow users to send friend requests and then show the friends in a separate section of the leaderboard. You can also use this friend system to allow sending messages only between accepted friends to prevent spam in your in-app messages. This improvement is live in the released card game One Card! for iOS and Android.
    onecard-menu onecard-game
    Download One Card on iOS Download One Card on Android
  • With the AppButton::textFont property, you can now access and modify all font properties of the text within AppButton.
  • The Component Showcase Demo App configuration for ios/Project-Info.plist now includes the NSContactsUsageDescription entry, which is required for NativeUtils::storeContacts() since iOS 10.
  • Use the new Dialog::autoSize property to decide whether the dialog uses a fixed height or a dynamic height based on the Items you add as dialog content.
  • Incorrect warning for publish builds about using DEPLOYMENTFOLDERS is no longer displayed when QRC is actually used instead. This is relevant when protecting your source code for published apps.

Qt 5.9 Improvements for Mobile App Development

Qt 5.9 added many improvements and was shipped on time. This indicates that the new CI system The Qt Company is now be using yields great results. These are our favorite Qt 5.9 improvements, with a focus for mobile app or game development:

Qt 3D: Animations, Physics Based Rendering (PBR), Level of Detail

Qt 3D got a lot better with the Qt 5.9 release. These are our highlights:

  • You can now use key frame animations! This is an important feature, as it allows you to animate your 3d objects in a dedicated animation tool like Blender or Autodesk Maya, and then import this animation with Qt 3D.
  • A Physics Based Rendering (PBR) material is now available in Qt3DExtras.
  • A new Level of Detail component allows loading different 3D models based on projected screen size or distance. This enables you to have better performance.
  • You can now render Qt Quick 2 scenes to a texture and interact with them in a 3D world.
  • 3D text is available in Qt3DExtras:

Improved QML Performance

Thanks to support for ahead-of-time generation of QML type caches and support for shader program binaries now being cached, the initial application startup time, QML loading time and also view initialization times got improved. Also, the rewritten JavaScript garbage collector yields better performance.

Qt Location and Positioning

  • You can now tilt and rotate maps, both through the APIs and through touch gestures.
  • If you want to overlay items to maps this is now easier too.
  • On iOS, you can now collect positioning data even when the application is in the background.
  • There’s also a new plugin that adds support for Mapbox and both raster and vector tiles, using their OpenGL based map rendering engine:

Mapbox OpenGL Plugin

GamePad Support and More

Qt now supports GamePads which is great for improving controls for games on PC, Android, iOS or tvOS devices. The GamePad support works nicely together with the V-Play TwoAxisController component, which is used in several of the sample games available like our Super Mario like platformer game.

Other improvements like Qt NFC support when running as an Android service or better Qt Charts makes this the best Qt release yet. For a list of all new features in Qt 5.9, see here.

Qt Creator 4.3 Support

The absolute highlight of Qt Creator 4.3 is the new live preview of your QML code in the Qt Quick Designer (alias QML Designer):

Qt Quick Designer - Mixed Design and Edit Mode


It allows editing the QML code side by side with the form editor as a preview. In addition to this preview, you can also use the property editor together with the text editor. Qt Quick Designer will always select the item that currently contains the cursor.

So if you just forgot the name of a property or enum, you can now use the property editor instead. With the improved designer, you can now create UIs seamlessly by mixing QML code and visual editing. This really combines the best of two worlds, because you can now stay in the design mode instead of switching between code and design modes.

Internally, we were using the Code editing mode most of the time. We have now changed our workflow and development process to use the designer more and have already experienced a faster development process. We’d highly recommend you to try out the new design mode, it will save you a lot of hours and makes development with QML even better. :)

See here for a detailed list of new Qt Creator 4.3 featuers, and here for a list of Qt Quick Designer improvements.

How to Update V-Play

Test out these new features by following these steps:

  • 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.12.0 as described in the V-Play Update Guide.

V-Play Update in Maintenance Tool

  • After updating, remove Qt 5.8 from your installed components: Click on “Add or remove Components” and unselect Qt 5.8. Because V-Play is not compatible with Qt 5.8 anymore, it is best to remove these kits.
  • When you now start Qt Creator, it automatically detects the kits for Qt 5.9, which you can use to build your V-Play projects.
  • To enable one of the new Qt 5.9 kits, click “Projects” on the left side of Qt Creator and enable your desired kit in the section “Build and Run”.

If you haven’t installed V-Play yet, you can do so now with the latest installer from here. Now you can explore all of the new features included in V-Play 2.12.0!


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

More Posts Like This


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

How to Make a Qt app

Release 2.11.0: All Monetization Plugins Now Free, Plugin Trial & Firebase Qt Plugin

Release 2_11

WeAreDevelopers Conference App – Open Source & Live Now!



The post Release 2.12.0: Qt 5.9 & Qt Creator 4.3 Support appeared first on V-Play Engine.

Using Compiler Explorer with Qt

One of my preferred developer tools is a web called Compiler Explorer. The tool itself is excellent and useful when trying to optimize your code.
The author of the tool describes it in the Github repository as:

Compiler Explorer is an interactive compiler. The left-hand pane shows editable C/C++/Rust/Go/D/Haskell code. The right, the assembly output of having compiled the code with a given compiler and settings. Multiple compilers are supported, and the UI layout is configurable (the Golden Layout library is used for this). There is also an ispc compiler for a C variant with extensions for SPMD.

The main problem I found with the tool is, it does not allow to write Qt code. I need to remove all the Qt includes, modify and remove a lot of code…

So I decided to modify the tool to be able to find the Qt headers. To do that first of all, we need to clone the source code:

git clone

The application is written using node.js, so make sure you have it installed before starting.

The next step is to modify the options line in etc/config/

-fPIC -std=c++14 -isystem /opt/qtbase_dev/include -isystem /opt/qtbase_dev/include/QtCore

you need to change /opt/qtbase_dev with your own Qt build path.

Then simply call make in the root folder, and the application starts running on port 10240 (by default).

And the mandatory screenshoots 🙂



The post Using Compiler Explorer with Qt appeared first on Qt Blog.

Digital Instrument Cluster with Qt Quick Designer and Qt Safe Renderer

The growth of reconfigurable digital instrument clusters in the automotive industry is exploding. This is driving a need for high performance graphics technologies, designer tooling and solutions for safety critical systems.

The highly optimized Qt Quick technology is a great fit for creating modern digital clusters. Its plug-able back-end technology supports various rendering methods from OpenGL down through OpenVG to software rendering. This flexibility means you can target a wide range of price/performance points such as the NXP i.MX6 family which ranges from quad core with GPU to single core and no GPU.

For the designer, the Qt Quick Designer allows you to design and prototype the cluster user experience without writing any code. If you do chose to edit the QML code the your changes are immediately reflected in the live preview feature of Qt Quick Designer.

Safety critical operation is a key requirement in digital clusters. To satisfy safety requirements the safety critical functionality is separated from the other parts. What the automotive industry calls tell-tales is the safety critical part, these are the warning lamps for things such as airbag, oil level, engine temperature and brakes. These need to be rendered in a separate software partition that has been certified as designed and implemented per the industry’s relevant standards. The Qt Safe Renderer is our implementation that meets these standards.

But UI designers don’t really want to be bothered by such details. They just want to design the UI as a whole, marking items as safety critical is about the extent of what they need to know. We have added this capability into the Qt Quick language and Qt Quick Designer and to make things even more convenient this is done automatically when using one of Qt’s comprehensive set of ISO 7000 standard icons for warning and other indicators. Qt’s drag-and-drop visual design tooling really simplifies this design flow for adding these icons.

Once the design is complete the build process separates the safety critical UI elements from the main UI.  We use the Qt safe Renderer component to render the safety critical items and also to monitor the operation of the main UI. It is critical that any error in operation of the main UI does not impact the correct rendering of the safety critical items. The Qt Safe Renderer will restart the main UI as appropriate should it detect an error. For more details on the Qt Safe Renderer check out this blog post.

To show how all this comes together we created a video. It shows how to design a digital instrument cluster, deploy it to a device and how the Qt Safe Renderer works in practice.

As you can see, Qt offers tools that make design and prototyping digital instrument clusters intuitive for people who prefer visual design tools over coding. As always with Qt, the full power of QML, the Qt framework and C++ are accessible to create even more complex system logic.

You can get going quickly by looking at the code for the digital instrument cluster example used in the video in the Qt examples repository. Some of the Qt Quick components of the example have backends written in C++ which means they need to be built in order to be available in Qt Quick Designer. To do this, build the project for your desktop platform and in Qt Creator go to Tools > Options > Qt Quick > Qt Quick Designer and enable Use QML emulation layer which is built by the selected. For more details on how to integrate custom QML modules have a look at the Qt documentation here.

Contact us to learn more and discuss your needs in more detail.

The post Digital Instrument Cluster with Qt Quick Designer and Qt Safe Renderer appeared first on Qt Blog.

A tale of 2 curves

As my first subject for this animation blog series, we will be taking a look at Animation curves.

Curves, or better, easing curves, is one of the first concepts we are exposed to when dealing with the subject of animation in the QML space.

What are they?

Well, in simplistic terms, they are a description of an X position over a Time axis that starts in (0 , 0) and ends in (1 , 1). These curves are …

The post A tale of 2 curves appeared first on KDAB.

Vulkan Support in Qt 5.10 – Part 2

In the previous instalment we looked at the background for Qt 5.10’s upcoming Vulkan support. Let’s now start digging out into the details.

Obtaining a Vulkan-Enabled Qt Build

When building Qt from sources on Windows, Linux or Android, Vulkan support is enabled automatically whenever a Vulkan header is detected in the build environment. Windows is handled specially in the sense that the environment variable VULKAN_SDK – set by the LunarG Vulkan SDK – is picked up automatically.

Check the output of configure (also available afterwards in config.summary):

Qt Gui:
  Vulkan ................................. yes

If it says no, go to qtbase/config.tests/qpa/vulkan, run make, and see why it did not compile.

As mentioned in part 1, neither the QtGui library nor the platform plugins link directly to libvulkan or similar. Same applies to Qt applications by default. This comes very handy here: a Vulkan-enabled Qt build is perfectly fine for deployment also to systems without any Vulkan libraries. No headache with missing DLLs and such. Naturally, once it turns out Vulkan is not available at runtime, QVulkanInstance::create() will fail and will return false always. It must also be noted that the applications themselves can choose to link to a Vulkan (loader) library, if they have a reason to do so: all it takes is adding LIBS+=-lvulkan or similar to the .pro file.

Getting a Vulkan Instance

In Vulkan all per-application state is stored in a VkInstance object, see the the specification for a detailed overview. In Qt, Vulkan instances are represented by QVulkanInstance. This is backed by a QPlatformVulkanInstance following the usual QPA patterns. The platform plugins, at least the ones that are interested in providing Vulkan support, are expected to provide an implementation for it under the hood. As described earlier, this currently covers windows, xcb and android.

Following the familiar pattern from QWindow and the QOpenGL* classes, QVulkanInstance performs no initialization until create() is called. The loading of the Vulkan library (or the loader library which in turn routes to a vendor implementation) happens only at this point. (with a few exceptions, see below)

The resulting VkInstance can be retrieved via vkInstance().

Quite unsurprisingly, QVulkanInstance allows specifying the usual instance configuration options, like the desired API version, and, most importantly, the list of layers and extensions to enable.

While the Qt APIs allow including unsupported layers and extensions too – since it filters them out automatically – it may still be necessary in some cases to examine the names and versions of all supported layers and extensions. This can be done at any time – even before calling create() – via supportedExtensions() and supportedLayers(). These will naturally trigger an early loading of the Vulkan implementation when needed.

It is worth knowing that the surface-related extensions that are required for basic operation, such as VK_KHR_surface or VK_KHR_win32_surface, are automatically added to the list by Qt, and applications do not have to worry about these.

Typical main() Patterns

In the end the main() function for a Qt application with a Vulkan-capable window (or a Vulkan-capable window embedded into a QWidget hierarchy) will typically look like the following:

int main(int argc, char **argv)
    QGuiApplication app(argc, argv); // or QApplication when widgets are involved

    const bool enableLogsAndValidation = ...

    QVulkanInstance inst;

    if (enableLogsAndValidation) {

#ifndef Q_OS_ANDROID
        inst.setLayers(QByteArrayList() << "VK_LAYER_LUNARG_standard_validation");
#else // see Android-specifics at
                       << "VK_LAYER_GOOGLE_threading"
                       << "VK_LAYER_LUNARG_parameter_validation"
                       << "VK_LAYER_LUNARG_object_tracker"
                       << "VK_LAYER_LUNARG_core_validation"
                       << "VK_LAYER_LUNARG_image"
                       << "VK_LAYER_LUNARG_swapchain"
                       << "VK_LAYER_GOOGLE_unique_objects");

    if (!inst.create())
        qFatal("Failed to create Vulkan instance: %d", inst.errorCode());

    MyVulkanWindow w;
    w.resize(1024, 768);;

    return app.exec();

In most cases there will be a single QVulkanInstance. This can live on the stack, but has to be ready before creating the QWindow or QVulkanWindow-derived window objects since they will need to be associated with a QVulkanInstance. (more on this and other window-related topics in part 3)

The logging category qt.vulkan can be very helpful for troubleshooting. When enabled, both QVulkanInstance and, if used, QVulkanWindow will print a number of interesting things on the debug output, during initialization in particular. The hard-coded setFilerRules() call in the code snippet above is not necessarily the best approach always, but works well for platforms where environment variables (QT_LOGGING_RULES) are problematic. On Windows and Linux it is better to control this via the environment or configuration files.

When it comes to output from Vulkan and, first and foremost, the validation layers, QVulkanInstance offers the convenience of automatically redirecting these messages to qDebug. By default VK_EXT_debug_report gets enabled and redirection is active. If this is not desired, set the corresponding flag before calling create().

For example, the output from the hellovulkancubes example running on an NVIDIA Shield TV with Android 7.0 will look something like the following. If there were validation errors, they would show up too in a similar manner.

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]
Supported sample counts: QVector(1, 2, 4, 8)
Requesting 4x MSAA
qt.vulkan: queue family 0: flags=0xf count=16 supportsPresent=1
qt.vulkan: Using queue families: graphics = 0 present = 0
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
qt.vulkan: Color format: 37 Depth-stencil format: 129
Renderer init
qt.vulkan: Creating new swap chain of 2 buffers, size 1920x1080
qt.vulkan: Actual swap chain buffer count: 2 (supportsReadback=1)
qt.vulkan: Allocating 33423360 bytes for transient image (memtype 0)
qt.vulkan: Allocating 66846720 bytes for transient image (memtype 0)

Working with External Graphics Engines

Our final topic for this part is the question of integrating with existing, external engines.

During the lifetime of the Qt 5.x series, there has been a growing focus on making Qt Quick and the underlying OpenGL enablers more interoperable with foreign engines. This led to productizing QQuickRenderControl, the enhancements to QOpenGLContext for adopting existing native contexts, and similar improvements all over the stack.

In the same spirit QVulkanInstance allows adopting an existing VkInstance. All this takes is calling setVkInstance() before create(). This way every aspect of the VkInstance creation is up to the application or some other framework, and QVulkanInstance will merely wrap the provided VkInstance object instead of constructing a new one from scratch.

That’s all for now, stay tuned for part 3!

The post Vulkan Support in Qt 5.10 – Part 2 appeared first on Qt Blog.

CMlyst 0.3.0 released

CMlyst is a Web Content Management System built using Cutelyst, it was initially inspired by Wordpress and then Ghost. So it's a mixture of both.

Two years ago I did it's first release, and since them I've been slowly improving it, it's been on production for that long providing web site/blog. The 0.2.0 release was a silent one which marks the transition from QSettings storage to sqlite.

Storing content on QSettings is at first quite interesting since it's easy to use but it showed not suitable very fast, first it kept leaving .lock files, then it's not very fast to access so I had used a cache with all data, and a notifier updated that when something changed on the directory, but this also didn't properly triggered QFileSystemWatcher so once a new page was out the cache wasn't properly updated.

Once it was ported to sqlite, I decided to study how Ghost worked, this was mainly due many Qt/KDE developer switching to it. Ghost is quite simplistic, so it was very easy to try to provide something quite compatible with it, porting a Ghost theme to CMlyst requires very little changes due it's syntax being close to Grantlee/Django.

Due porting to sqlite it also became clear that an export/import tool was needed, so you can now import/export it in JSON format, pretty close to Ghost, actually you can even import all you Ghost pages with it, but the opposite won't work, and that's because we store pages as HTML not Markdown, my feeling about markdown is that it is simple to use, convenient to geeks but it's yet another thing to teach users which can simply use a WYSIWYG editor.

Security wise you need to be sure that both Markdown and HTML are safe, and CMlyst doesn't do this, so if you put it on production be sure that only users that know what they are doing use it, you can even break the layout with a not closed tag.

But don't worry, I'm working on a fix for this, html-qt is a WHATWG HTML5 specification parser, mostly complete, but the part to have a DOM, is not done yet, with it, I can make sure the HTML won't break layout and remove unsafe tags.

Feature wise, CMlyst has 80% of Ghost features, if you like it please help add missing features to Admin page.

Some cool numbers

Comparing CMlyst to Ghost can be trick, but it's interesting to see the numbers.

Memory usage:

  • CMlyst uses ~5MB
  • Ghost uses ~120MB

Requests per second (using the same page content)

  • CMlyst 3500/rps (production mode), 1108/rps (developer mode)
  • Ghost 100/rps (production mode)

While the RPS number is very different, on production you can use NGINX cache which would make the slow Ghost RPS not a problem, but that comes to a price of more storage and RAM usage, if you run on an AWS micro instance with 1GB of RAM this means you can have a lot less instances running at the same time, some simple math shows you could have 200 CMlyst instaces vs 8 of Ghost.

Try it!

Sadly it's also liked soon I'll be forking Grantlee, the lack of maintenance just hit me yesterday (when I was going to release this), Qt 5.7+ has changed QDateTime::toString() to include TZ data which broke Grantlee date filter which isn't expecting that, so I had to do a weird workaround marking date as local to avoid the extra information.

Mobile App Development with Qt Part 1 – Top Considerations for Choosing Your App Development Framework

by Christian Feldbacher, V-Play [Qt Technology Partner] (Qt Blog)

Choosing a framework for your next cross-platform app is an important decision. In this post we’ll cover multiple factors to consider when choosing your app development framework and how that should support your business strategy.

What to Consider

Determine the reasons why you may need a cross-platform mobile app:

  • Do you want to improve your brand and better position your company in mobile app stores?
  • Do you want to make your employees more productive with internal apps that they can use on their tablets or phones?
  • Do you want to save the cost of having a dedicated Android and iOS development team and instead have one team that’s able to cover all platforms with a single source code basis?
  • Will you have to maintain your app on multiple platforms over a long period of time? Your iOS and Android versions may drift apart in terms of functionality and features because maintaining multiple platforms requires a lot of effort and dedicated experts for iOS and Android. With a cross-platform solution, you can avoid different timelines per platform and reduce maintenance costs.
  • Do you need to reduce the amount of duplicate code for multiple platforms such as iOS, Android and Desktop?
  • Do you have existing business logic or even a desktop application written in C++ and now want to bring it to mobile?

If you answer yes to just a couple of these questions, you should be considering a cross-platform mobile app strategy.

Let’s dive into the question, what your cross-platform framework should provide:

Animated UIs

Successful apps all have one thing in common: a great user experience and smooth animations that give the user a sense of joy.

So to create a modern mobile app, the user interface and the screen transitions need to be animated. Adding animations and prototyping different UIs should be the core strength of your framework. Take Qt Quick (aka QML) as an example – QML was essentially designed and written with this goal in mind.

If you’ve developed native apps for Android or iOS before, you’ll know that getting these animations right is a major time sink. Using a declarative design approach will save you time and money.  QML allows you to easily animate any user interface element with dozens of different easing types and gives your app that extra level of polish

(Very) Few Lines of Code

Another benefit of QML is its declarative structure: You can define UIs and animations in less than 20 lines of code and they’ll still be easy to understand and read. With advanced features, such as property bindings, you can save even more lines of code. This requires a lot of boilerplate code in other programming languages.

Native Performance

The basis of QML is C++ which has much better performance than any JavaScript-based framework. In addition, the rendering of QML is handled from a modern scene graph optimized for mobile. Thanks to this scene graph and C++ basis, the animations and loading times are on a native level, just like a regular iOS or Android app.

Business App Requirements

Qt supports many requirements in modern business apps. It allows you to access your backend APIs via WebSockets or REST/HTTP, add location and maps services, display HTML 5 content, access sensors, multimedia, databases, localization features, and more connectivity access via Bluetooth LE or NFC.

Compatibility with Your Existing Business Logic

If you have existing business logic in C++, you can include that code and reuse it for your mobile apps. You don’t need to start from scratch and can focus on providing a great UI to users.


If a native feature you need is not covered by Qt yet, you can add it on your own and then provide it to QML with a clean scripting API, from native Java or Objective-C/Swift code to QML. This also allows you to add 3rd party SDKs, which might only be available for iOS or Android. Some of the most popular mobile services are available in a cross-platform format as V-Play Plugins – see the upcoming part 2 for more details.

Components Designed Specifically for Mobile App Development

Qt with QML fulfils many mobile app requirements, but you can make it even better by taking advantage of components that are specifically designed for mobile app development, such as those available in the V-Play Apps SDK , which provides components on top of Qt to simplify and accelerate mobile app development with Qt.



V-Play Apps components were designed with mobile-first in mind. This means you get components used by the most successful and popular mobile apps on iOS and Android as cross-platform components.

This is the first part of the “Mobile App Development with Qt” series. In the second part, you will learn about the differences between platforms and how you can support these differences with a shared code base using Qt and V-Play Apps.

As soon the second part is released, the link will be added here.

The post Mobile App Development with Qt Part 1 – Top Considerations for Choosing Your App Development Framework appeared first on Qt Blog.

GammaRay 2.8.0 Release

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

A big focus in this release is improvements to the Qt Quick inspector, which gained layout helper grids and Qt Quick Controls 2 tracing, as well as initial support for the software renderer. We have also optimized the performance of the remote view, which previously managed to saturate a …

The post GammaRay 2.8.0 Release appeared first on KDAB.

Monkeystudio homepage is moving


After some months (years :p) without any special move in MkS I decided to *archive* the website.
Currently it cost me a lot of time to maintain the web part of the MkS project, update drupal, update any of its modules etc.
This is inefficient because to be honest, nothing in this CMS is serving us apart the blog/story/wiki.
So I decided to move to a plain html/js static website which posts, blogs and wiki pages are just requested from xml request from a json file.
i will just have to update this json file to add any new content, very easy to handle / maintain.

read more

Built with Qt: Episode II – Driving the Automotive Industry

Qt is putting the pedal to metal within the automotive industry with our Qt Automotive Suite offering and we have a lot of interesting automotive related #BuiltwithQt cases, videos and demos. We are attending TU Automotive in Detroit this week, where both our partners and The Qt Company will have booths displaying the latest and greatest within automotive.

We had so many automotive showcases at Embedded World 2017, from both our partners and The Qt Company, and in this blog you will find some of the selected ones. It is really cool to see how this industry is driving technology forwards with innovation. There is a good chance you’ll see some of these demos at the TU Automotive event as well.

Multi-screen demo on single SoC with Integrity RTOS

As the pressure on proving a unified UX across all screens within automotive is rising, there is also a pressure to keep costs down. QML can save you up to 40% off the hardware cost and really allows you to squeeze the juice out of your hardware. In the following video you can see our multi-screen demo, running on a single SoC using Integrity RTOS and the application manager in the Qt Automotive Suite, based on the Wayland Compositor, for managing the complex architecture.

Gesture Controlled Infotainment

Like straight out of Minority Reports, gesture control is on the horizon – who likes talking to your car anyways when you can make hand gestures to control the temperature of your car? The future is interesting. Check out the gesture controlled IVI using Qt Automotive Suite with our partner, brightONE:

All-in-One Carputer

Our partner, LinkMotion has developed something they call a Carputer, it’s a nifty name for an all-in-one solution consisting of hardware and the Qt Automotive Suite supporting. Oh, and the Carputer is used by a car manufacturer that creates super-fast cars. Some might know them as the raging bull of the automotive industry. Check out LinkMotion’s demo of their Carputer:

Worlds Fastest Electric SuperCar

Not only is the raging bull of automotive using Qt, but our friends over at Rimac Automobili have created the world’s fastest electric supercar with a Qt based IVI and digital instrument cluster. The world’s fastest electric supercar deserves the world’s fastest software and there is no wonder why they choose Qt. I could also name some other fast electric mass produced cars who have their in-vehicle screens built with Qt (they might be from Californi-a), but I’ll save that for later. As Damir from Rimac so nicely states: “The Rimac Concept_One is limited to 355 km/h or 220 mph” ­– I wonder how fast it can go without the limitation. And how fast will cars go when they are all autonomous? The roads will be far safer. Will there even be speed limits?

TU Automotive

We are going to be at TU Automotive in Detroit this week. Do come and see us and talk with us about what we can do for your automotive program. Here are some of the featured partner demos at TU Automotive which are built with Qt!

  • Harman | HCAT HMI Solution & Echo Cancelations and Noise Reduction software 
  • Green Hills | Automotive Instrument Cluster HMI built with Qt on INTEGRITY 
  • QNX | QNX Hypervisor, instrument cluster and infotainment built with Qt and featuring Qt, HTML and GL 
  • Mapbox | Qt Automotive Suite running on Intel NUC featuring Mapbox Vector Map integration

At the Qt booth we will be showing:

Multiple Display Synchronization with a Single Processor

Streamline reference UI/UX designs for IVI systems including multiple IVI applications and application store development

  • Independent App process per app enables modern updating functionality
  • Display on multiple screens
  • Qt Wayland Compositor for display composition
  • Embedded Linux running on Intel NUC
  • Qt Automotive Suite

Qt Fast Boot Instrument Cluster  

Boot up your project in 1.2 seconds with Qt (Qt applications are not the limiting factor – the OS and hardware is)

  • Toradex Apalis NXP i.MX6 Quad core processor, 1GHz
  • 1GB DDR3 RAM, 4GB eMMC
  • 1280 x 480 Display
  • Embedded Linux Qt for Device Creation

Check out the Toradex Apalis i.MX6 going head to head with the NXP Sabre i.MX6 to achieve the fastest boot time on a digital instrument cluster:

Qt 3D Studio for Future Automotive Instrument Cluster UX/UI

Qt 3D Studio is an authoring tool for rapidly creating interactive 3D interfaces and applications and was the biggest contribution to Qt ever. Thank you, NVIDIA!

  • WYSIWYG editor for 3D scenes and animations
  • Application deployed on Intel NUC and Google Pixel C
  • Built material and effects library
  • Mix 2D and 3D user interfaces by integrating Qt Quick
  • Combining Qt 3D Studio, Qt Quick Designer, and State Chart Editor

Check out how a 3D HMI is built in less than 30 minutes in the following video:

Qt Automotive Suite gets you first to the finish line whether is in your software development project or in one of the super-fast cars running Qt. If you have questions about creating the digital automotive cockpit of the future, whether it be a cluster with safe rendered components extended with a heads-up display, smack bang in the middle of your windscreen, showing you the way to go in an augmented reality futuristic way or an IVI with a branded look and feel across all screens. And with Qt you can also re-use your code so if you want to put your cockpit in your pocket with our mobile offering and create your companion app for iOS or Android – we’ve got you covered. Qt really does have everything you need for your automotive program. We even create branded SDKs to make sure your teams and third parties are all aligned using the same tools and libraries. Contact us or come talk to us at TU Automotive. Be there or be…well…outdated.

The post Built with Qt: Episode II – Driving the Automotive Industry appeared first on Qt Blog.

Creating PDF/A documents with Qt

As there were some complex issues around conformity in PDF document creation within Qt, KDAB let me spend some time digging into it so we could make sure that Qt’s PDF engine generates documents up to ISO-standard.

Nowadays, many official institutions have the requirement to archive their data digitally and PDF is a first class citizen for this purpose. However, since the overall PDF standard is too complex, to guarantee that PDF documents can be rendered in their entirety in

The post Creating PDF/A documents with Qt appeared first on KDAB.

Renewed Qt Support Services

The Qt Company support team works hand-in-hand with Qt R&D developers and we are 100% committed to ensuring that you succeed with your project.

We have recently launched new support services and in this blog post I would like to introduce you to the new offering and in addition give you an introduction to the Qt Support team. The new support offering has been modified and we have launched two different levels of support, which have been named ‘Standard’ and ‘Premium’ Support. In addition to our standard offering, all 5.x releases can be extended with Extended Support.

The Team

We have a team of experienced software engineers working in Qt Support. All of us have a long background in software development and with Qt. Currently we are working from three different locations, Oulu, Oslo and Santa Clara and we are considering expanding our locations to Tokyo, Berlin and Boston during this year.
With new locations covering multiple time zones, we will be able to give even quicker responses to our Asian and US based customers.
The Qt Support team is part of Qt R&D and we work closely with the development teams. Being closely connected with where the development happens means that we are always up to date with the latest new features and we know the best practices on how to leverage these new features. For you as a Qt user, it also means that if you have an issue, we know who to contact and we can solve your challenges quickly.

Standard and Premium Support

Earlier we had three different support levels, but now we have reduced those to two and changed the names of two levels moving forwards. The previously known Silver Support will now be called ‘Standard Support’. The SLA terms are still the same as earlier with Silver Support. The new Support plan name, Standard Support, will be visible to you in your Qt Account.
Gold support has been renamed to Premium Support. Current Gold support customers will continue to get their service under the old Gold Support SLA.
The entry level support, Bronze Support has been phased out.

All Qt customers with an active license (except for start-up licensees) are entitled to Qt Support. Standard Support is bundled with all new Qt licenses. It comes with a two business day response time guaranteed and provides you priority to the customer reported Qt errors.
If a more personal and quicker support service is required, the Premium Support is the way to go. With Premium Support, we offer a dedicated support person and the possibility to utilize online chat through remote desktop connection. With Premium Support, our target is to respond within the same workday as the issue is reported. Also, reported bugs and other issues are treated with even higher priority than with Standard Support. With Premium Support, we also analyze the complete customer application code base and debug that instead of requiring a minimal test application where the issue is reproduced.

Support Level Details
Standard Support Premium Support
Support on Qt APIs, functions, methods and programming techniques Yes Yes
Guaranteed response time Within 48 business hours Within 24 business hours
Bug fix prioritization* Priority High Priority
Support on using Qt for your specific project Yes
Dedicated Qt Support contact Yes
Instant messaging with dedicated support contact Yes

*Within reasonable efforts, not every bug is fixable as part of Qt Support

Extended Support

Qt 5.4 and later releases are currently supported by default. If support is required for older and unsupported Qt 5.x releases the support can be separately purchased as Extended Support. This will allow the customer to ask questions and report issues occurring on these older Qt versions – in the same way as if the phased out Qt version was still officially supported.
By default, releases from Qt 5.6 and onward are supported for one year and LTS releases are supported for three years starting from the 5.x.0 release.

Support periods for Qt 5.x releases
Qt Version Standard Support Until Extended Support Available
5.0.x – 5.3.x Support already ended. Yes
5.4.x 01.07.2017 Yes
5.5.x 16.03.2018 Yes
5.6.x (LTS) 16.03.2019 Yes
5.7.x 16.06.2017 Yes
5.8.x 23.01.2018 Yes
5.9.x (LTS) 31.05.2020 Yes

More information regarding the different support levels can be found on the Qt Support pages.
Both Extended Support and Premium Support upgrades are targeted for complete development teams.

The Help We Provide

In most cases, Support provides a fix or a workaround for the reported issue. The remaining issues are then followed up by our development teams. Qt Support flags these bugs as being originating from commercial customer and thus gets higher priority when R&D prioritizes bugs to be fixed. Therefore, it is important that all the bugs that the commercial Qt customers encounter are also reported to the Qt Support team.

Even though helping customers tackle Qt bugs is a prominent function of the support team, we also do a lot more. Most questions sent to Support are actually not related to bugs, but rather related to finding optimal coding solutions for the problems customers are facing in their code. We have also been compiling a Qt Support FAQ page, which deals with the most common issues. The Qt Support FAQ is accessible through your Qt Account.

We have been measuring Qt support customer satisfaction for many years now and we have always had a high rating. 9/10 customers have been satisfied or very satisfied with our service. Our main target is to keep our customers happy and productive with Qt. The future of our framework relies on successful projects and therefore we put a lot of effort into providing the best support possible.

You can find more information about Qt Support on the support pages or via Qt Account and we are also more than happy to provide you with a quote. Please do contact us if you have any questions regarding our offering.

The post Renewed Qt Support Services appeared first on Qt Blog.

Vulkan Support in Qt 5.10 – Part 1

As some of you may have heard, one of the new features in Qt 5.10 is the introduction of a set of basic Vulkan enablers. Now that Qt 5.9 is out, it is time to take a look at what this covers (and does not cover) in practice. In order to keep things fun and easy to read, this is going to be split into a series of shorter posts. It must also be mentioned that while the new features mentioned here are all merged to the dev branch of qtbase, there is no guarantee they will not change until the release of Qt 5.10.


Qt 5.8 started the research and implementation for gradual improvements when it comes to supporting graphics APIs other than OpenGL. There the focus was mainly on Qt Quick, and scenegraph backends that either do not involve new platform specifics (software) or are available on a single platform/windowing system only (Direct3D 12).

As shown in the pre-work for our D3D12 experiment, getting started with such APIs is easy: 1. grab the native window handle (for example, in case of Windows, QWindow::winId() is the HWND); 2. add your platform-specific code to render stuff; 3. done!

Now, the same is of course possible with Vulkan, as proven by the various projects on GitHub and elsewhere. So what is the point in touching QtGui, the QPA interfaces, and the platform plugins?

Well, things become more interesting when multiple platforms come into play: the way windowing system integration is done in Vulkan requires writing platform-specific code, likely leading to a bunch of ifdefs or similar in cross-platform applications.

Given that we have a cross-platform framework (Qt), it is fairly natural to expect that it should help with abstracting and hiding these bits.

So instead of this:

QWindow *window;

#if defined(VK_USE_PLATFORM_WIN32_KHR)
    VkWin32SurfaceCreateInfoKHR createInfo;
    createInfo.hwnd = (HWND) window->winId();
    err = vkCreateWin32SurfaceKHR(...);
    VkWaylandSurfaceCreateInfoKHR createInfo;
    err = vkCreateWaylandSurfaceKHR(...);
    VkAndroidSurfaceCreateInfoKHR createInfo;
    err = vkCreateAndroidSurfaceKHR(...)
#elif defined(VK_USE_PLATFORM_XCB_KHR)
    VkXcbSurfaceCreateInfoKHR createInfo;
    err = vkCreateXcbSurfaceKHR(...)
#elif ...

why not have something like the following:

QWindow *window;

VkSurfaceKHR surface = QVulkanInstance::surfaceForWindow(window);

The windowing system specifics are now conveniently handled in Qt’s platform plugins. No more ifdefs.

The second important motivation factor is that even the D3D12 experiment has shown that many applications are happier with a higher level convenience window class, like QD3D12Window, following the example of QOpenGLWindow. These are inherently limited in some ways, but avoid the need for doing everything from scratch with QWindow (and juggling with surfaces like in the above example…).

Using QWindow directly remains the most powerful way always, giving full control to the application, but as we will see later, doing a fully featured and stable Vulkan-based QWindow is not exactly trivial (think swapchains, exposeEvent(), resizing, QPlatformSurfaceEvent, etc.). Hence the introduction of QVulkanWindow.

What This Is Not

Before moving on to the new QVulkan* classes in detail, let’s clarify quickly what the Vulkan support in Qt 5.10 really is:

  • Qt 5.10 enables applications to perform cross-platform Vulkan rendering in a QWindow and the convenience subclass QVulkanWindow.
  • Besides abstracting the windowing system specifics, a thin wrapper is provided for Vulkan instances and the instance and device specific functions of the core Vulkan 1.0 API.
  • The Vulkan API is not abstracted or hidden in any way. Qt does what it should, i.e. helping with windowing, platform specifics, and function resolving for the core API, but no more than that.
  • Vulkan-based QWindows can be combined with QWidget-based UIs using QWidget::createWindowContainer(). They are no different from OpenGL-based windows in this respect. This is excellent news for 3D tooling type of applications on the desktop using QWidgets, since there is now a Vulkan-based alternative to QGLWidget/QWindow/QOpenGLWindow.
  • Vulkan support does not currently cover modules like Qt Quick, Qt 3D, Qt Canvas 3D, the OpenGL backend of QPainter, the GL composition-based QOpenGLWidget/QQuickWidget, etc.
  • Vulkan support may be introduced to some of these in the future, however this is not in scope for Qt 5.10.


So what platforms are supported?

As of Qt 5.10, the situation is the following:

  • Windows (desktop, not WinRT): when the LunarG SDK is installed, and thus the VULKAN_SDK environment variable is set, Vulkan support will automatically get enabled in the Qt build.
  • Linux (xcb only at the moment; support in the wayland platform plugin to be added later on): enabled whenever the Vulkan headers are found during configure time.
  • Android (tested on API level 23 and 24; note that the Vulkan headers (and related tools) are only present in level 24 and newer NDKs out of the box)

Note that Qt’s Vulkan support does not rely on linking to a Vulkan (or loader) library, and rather relies on resolving everything at runtime. Therefore the only hard requirement is the presence of a relatively recent set of Vulkan headers (like > 1.0.13 or so).

When it comes to the pre-built packages, we currently have some open tasks to investigate and implement support for Vulkan-enabled builds on some platforms at least. Hopefully this gets sorted out in time for Qt 5.10.

That’s it for part 1. Stay tuned for part 2, where we will start digging into the actual QVulkan classes!

The post Vulkan Support in Qt 5.10 – Part 1 appeared first on Qt Blog.

Qt for web (assembly)

So ya, I have been doing work for the up and coming Finnish company Intopalo getting Qt5 for WebAssembly using emscripten up and running. This is the 3rd Finnish company I have done work for, and the 4th Nordic company (Trolltech, Nokia, Jolla, Intopalo)

This is very much a work in progress.


There was a Qt4 version, emscripten-qt and a related Qt5 for Native Client which do similar things, and we have taken inspiration from both these projects. Thanks!

The gist of it:

We use emscripten to cross compile Qt5 into javascript and/or webassembly. We use 'incoming' from emscripten's git repo. Details how to build emsdk are here.

My working Qt5 repo is here, (the wm branch contains multi window and window decorations) while there is also an outdated WIP gerrit MR  which will get updated at some point.

This is how I configure Qt for emscripten:
 . ~/emsdk/ (to get em compiler in path)

~/depot/qt/qt5/qtbase/configure -xplatform emscripten -confirm-license -opensource -nomake tests  -nomake examples -developer-build -no-dbus -no-thread

 (no-thread is a new feature I added for this, as threading in javascript is basically non existent)

and then, use that qmake to compile a Qt app!

To run the app, in the firefox browser
emrun --browser firefox path/to/app.html

This is all bleeding edge from the emscripten compiler to the web assembly support in the browser, so your mileage may vary.

With the 'wm' branch of my github repo, multi windows and window decorations are kind of working. As well as compiling into webassembly and not just javascript asmjs.
Compiling into wasm brings much smaller download sizes, but you need to have a browser that supports it.

There is still heaps of work to do to bring it up to release state. So for now, it is still a research and WIP project, and a lot of things may or may not work. But it can run some Qt widget based apps in your (firefox) browser!

The future:

Currently there is no support for qml/qt quick. That just means we haven't tried it as our focus is currently on widgets and opengl.

Personally, I would like to see location and some sensor events, but that is for the future.

Getting started again

As you all probably know already, the crowdfunding for qutebrowser ended up being more than fully funded - thanks to everyone again!

The funds arrived on my bank account yesterday, minus some 10% fees for Kickstarter and payment processing. Yesterday also was the last day with lectures before my summer holidays!

Since Monday is a public holiday, I decided to spend some time today on sending out the stickers to everyone who doesn't have a t-shirt, and then continue next Tuesday with day 2.

Over the last few days, I also spent some time on getting QtWebEngine more ready:

For people who have t-shirts in their pledges, a survey will follow soon - I still need to sort out some things about available colors and sizes first.

If you're reading this via the Python or Qt planet, note that I won't post future minor updates there - if you want updates about what I'm doing currently (a few times per week), check the qutebrowser development blog!

CI Performance, HW and SW changes

This time I’ll cover the topics performance as well as upcoming hardware and software changes.


You have all noticed that the CI system is behaving poorly to what comes to the performance. Sometimes autotests take over 30 times longer to run compared to a normal situation. Now why is that?

We actually have different kinds of bottlenecks. One is the bandwidth with which the virtual machines (VMs) store local data to their virtual hard drives. The servers on which our virtual machines run have no local hard drives. They instead store all their data on a centralized storage called the Compellent ( So when a VM wants to store data on its virtual hard drive, the host it runs on actually stores the data on the centralized storage.

We have several generations of hardware installed, and they have different speeds on their SAN interface with which they are connected to the Compellent. As your build picks up a server, it can be a new rack server, or it can be an older generation Blade ( Also, all the other VMs on these servers share the same bandwidth, so depending on what the other builds do, your SAN connection can be affected. Sadly, our test of prioritization these VMs, didn’t produce expected results and really didn’t much at all.

These generations of hardware and type of hardware also affect the amount of other VMs the hardware can run simultaneously.  We have Mac mini’s running our macOS builds. Those generally run 1 VM per physical Mac mini. Then we have old Blades that run around 4 VMs per Blade. The latest additions to our hardware pool are dual socket 20 core CPU server racks. Those run up to 26 VMs simultaneously. Running more on the same hardware reduces costs for us, but also increases the odds of one build affecting the next.

Another bottleneck is the Compellent itself. The storage system has 120 + 10 spare hard drives spinning at 15K RPM. However great the IOPS performance is in that system, when we decide to start 200+ VMs in the CI, it goes down to its knees. And when it does that, all builds and autotest run are affected. You could think of this as you having 2 computers at home sharing the same spinning disk.

Now that all is grim and morbid, let’s continue with the good news.

Upcoming hardware changes

We’re replacing the current hardware stack with a completely new one. The parts have arrived and are being installed as I type right now. Not only did we acquire new hardware that is faster, but we also redesigned the building concepts so that they utilize the hardware differently. The new hardware can be easily expanded and we designed the system so, that we don’t produce bottlenecks even when expanding it.

Before I go in to details, I need to explain a bit how the CI systems generally works. So, heading off on a tangent here! When developer stages a commit in Gerrit (, the CI picks it (or multiple commits) up. The CI or Coin as the piece of software is figuratively called, generates work items based on the data received. If let’s say the commits was for QtDeclarative, Coin now produces work items for itself to handle that QtDeclarative build on top of circa 30 different target platforms. Each of these work items depend on QtBase to be built. So now Coin also creates these circa 30 work items for QtBase. As QtDeclarative is built on top of the current qt5.git’s QtBase, it means in normal situations that QtBase has already been built previously. These artifacts have been stored by Coin and can now be reused. So instead of rebuilding QtBase for QtDeclarative, Coin simply checks its storage and links the previous builds to the current one and promptly continues with building QtDeclarative. This is the major change in how we build Qt nowadays compared to old days with Jenkins where every build always rebuilt the entire stack up to its point. You may read more about it in this blog post.

Continuing into more details. Whenever Coin starts to build something, it needs a VM for the task. We have “templates” in vSphere that represent different operating systems. They are virtual machines that have operating systems installed in them along with some basic things set up like user accounts and SSHD etc. Then they have been shut down ready to be used. Now when a build needs a VM, it clones a template VM and launches the clone. The clone is actually only a linked clone. This means that we don’t really clone anything, but only create a new virtual machine that links or points to the original one. Now, when the new clone is powered on, it _reads_ from the original template, but all changes are _written_ to its own file called the ‘delta image’. This way a new virtual machine only takes up space that’s equal to the amount of data it has written.

Going back to the template again. I said that it only contained basic things like user accounts and SSHD. A build surely needs more than that. We need Visual Studios, MINGW, CMake, OpenSSH, XCodes, MySQL etc. installed as well. Those things are ‘provisioned’. In qt5.git we have a folder structure under /coin/provisioning that contains scripts that install these things. As there is no point in running them every time for every VM, we create yet another set of templates that contain these pre-installed. We call these TIER2 images (or templates) vs TIER1 images being the vanilla distros containing only the basic things enabling us to even use them.

TIER2 images work pretty much the same way as QtBase was a dependency for QtDeclarative. Each build we trigger checks the current configurations scripts from qt5.git and makes a SHA from the folder structure. This SHA is used in naming the TIER2 image. If the content we want to install has changed, we have to regenerate a new TIER2 image. This is called the provisioning and it’s triggered automatically if the requested TIER2 image doesn’t exist.

Now, let’s go back on track and talk about the hardware changes.

The new servers have local SSD drives that work as the storage for the VMs instead of a centralized storage. This removes the bottleneck of a SAN network and reduces latencies while at it. And while being SSD drives, they are faster by design to what the Compellent used to be with its rotating discs. We still have a Compellent, but this time it’s filled with SSD drives. While the VMs use local SSD drives on the hosts themselves to store data, reading is a more complicated thing.

The TIER1 and TIER2 images described earlier are still stored centralized on the Compellent. This saves us the transferring of the images to each server serving as the host for the VMs. These TIER2 images are cloned as normal, and then the read operations point to the source. This would cause the same situation as with the old system where everything is read from the Compellent, but we are relying on caches to work in our favor here. The TIER2 images are shared via NFS, and the host OS on the server is equipped with a 500 GB NFS cache. So, whenever something is read from the TIER2, it is in fact now read from the NFS cache that’s local. All this is obviously assuming that the data has been read once previously. In practice, if a TIER2 image gets updated, the data has to be read from the centralized storage once, and then it’s in cache for the rest of the builds. We also have to remember that not the entire TIER2 image is read whenever data is read. If a build requests, only those blocks containing the file are read.

We also need the Compellent to provide us with redundancy for critical systems and a huge data storage for data that can’t be stored distributed. Critical systems include our own infrastructure and the storage is needed for all kinds of data including our release packages, install packages, distro ISO images etc. So even if we had a good mechanism to distribute the entire TIER1 and TIER2 load to the servers themselves, currently there is no need for it and the Compellent serves this need more than well right now.

The new hardware infrastructure will include new switches and firewalls as well. And all these are being set up in new premises, so everything is new. With this we will expect a few maintenance breaks during the upcoming months where services are being handed over from one site to the other. The down times should be relatively low, since all data is being transferred beforehand and not during the down times.

Software changes

Currently Coin is using VMware’s vSphere technology to create and run VMs. That’s about to change. Our new spinal cord will be based on OpenNebula ( The swap to this new technology will come at the same time we switch to the new facility with the new hardware. We’ve been working hard to get the robustness and reliability up, matching or even exceeding the one provided by VMware’s products. With open source non-proprietary code we can go deep into the root causes of problems and fix drivers if that’s needed to make our VMs run smoothly without hick-ups. With OpenNebula being KVM based, we can expect new distro support to be available sooner as well. No longer do we need to fall back to saying a new macOS can’t be installed because VMware doesn’t support it. Let’s hope I can hold up to this promise or claim 😉

Performance wise the comparison between VMware and OpenNebula is a bit unfair since they use different underlying hardware, but we can say that builds aren’t going to get any slower by the looks of it.

We’re also working on getting all of our distros more provision scripted. This will make it a lot easier for anyone ( yes, this includes you ) to upgrade the software that’s being run on the VMs. Anyone can access qt5.git/coin/provisioning and modify / add scripts there. Normal code review procedures apply and TIER2 images get updated.

Internally we’ve had 3 different Jenkins instances in the past. We had one for CI that got replaced by Coin a year ago. The remaining two were for release package creation, Creator builds and few others, and the second one was for RTA standing for Release Test Automation where we verified the packages to really install something and examples working etc. Those two Jenkins instances are planned to be merged with Coin at some point in time, but for the time being they are going to stay there for a while. However, we’re improving the backend of how they receive their VMs. They currently compete with Coin in getting hardware resources. In the next weeks, this is going to be changed so that Coin creates these VMs. This takes away the race conditions between two back ends, but also gives our Jenkins instances “support” for OpenNebula VMs. Even if this does not show up directly to you as CI users, it should show up with slightly more reliable VM dedication, more effective cleanup of VMs, and at least from the technical perspective we should be more capable of producing packages faster.


The post CI Performance, HW and SW changes appeared first on Qt Blog.

KDAB contributions to Qt 5.9

Qt 5.9 has just been released!

This release marks two important milestones for the Qt Project. The first is that now the Qt 5 series has had more releases than any other Qt version ever (the last release of the Qt 4 series was Qt 4.8). The second milestone is that Qt 5.9 will be a Long Term Support release, therefore providing to many users a stable foundation to build their applications upon.

KDAB has been a significant contributor to this release, as shown by the number of commits by KDAB developers merged into Qt. In this blog post I will showcase some of the most outstanding contributions to Qt 5.9 developed by KDAB engineers. continue reading

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

Qt 5.9 released

I’m happy to let you all know that Qt 5.9.0 has just been released. A lot of work has been put into it, making Qt 5.9 the best Qt version we have developed so far.

With Qt 5.9, we have had a strong focus on performance and stability. We’ve fixed a large number of bugs all across Qt, and we have done a lot of work to improve our continuous integration system. This will make it a lot easier for us to create new releases (both patch level and minor releases) from 5.9 onward.

We’ve also added automated performance regression testing to our testing infrastructure, something that will allow us to continuously monitor our work on improving the performance of Qt. Please have a look at the separate blog post for more details.

The new configuration system used in Qt Lite has received many bug fixes, also here, you can find more detailed information in a separate blog post.

Long term supported

One major decision we have taken is to make Qt 5.9 another long-term supported (LTS) release. The previous LTS release, Qt 5.6, is starting to show it’s age, and many users have been asking for a more up to date version of Qt that they can use as a basis for long running projects.

Some of the major changes since Qt 5.6 include more than 2000 bug fixes all over Qt. Additionally, we are now using a C++11 compliant compiler with Qt which has allowed us to modernize our code base. We have also added the Qt Lite configuration system and made significant updates to our graphics architecture. This is in addition to all the other new things that have been implemented in Qt 5.9, explained in the following sections.

As an LTS release, Qt 5.9 will be supported for the next three years to come.

With our improvements on the CI and releasing infrastructure, we are convinced that we will be able to provide you with much more frequent updates and patch level releases for Qt 5.9 than we are able to do for the Qt 5.6 series. As a long term supported release, we will provide you with frequent updates in the first year. After the first year, we will gradually get more and more strict on the changes that will happen in the branch, so as a result, patch level releases are expected to happen somewhat less frequently for the second and third year.

We will as promised also continue to support Qt 5.6, but we strongly recommend everyone starting new projects to use Qt 5.9 as there are a lot of improvements across the board that will be of huge advantage to you.

Lots of new functionality

Even with our focus on performance and stability, we have managed to add more new features into Qt 5.9 than I can mention in this blog. For a more complete list have a look at the ‘New Features’ page in our wiki.

Here are some of the highlighted new features.

Core and Networking

Quite a few new features have been added in the Core and Networking modules. Starting at the base, Qt Core has two new classes. The first class, qfloat16 abstracts 16-bit floating point numbers, as these nowadays are increasingly more important for inter-operation with APIs which make use of the GPU. In addition, a new QOperatingSystemVersion class has been added to conveniently test for the operating system and version your application is running on.

Qt Network has gained support for HSTS (HTTP Strict Transport Security), improving security on HTTPS connections through QNetworkAccessManager.

Our NFC support in Qt NFC has seen some very nice improvements for Android, and Qt Web Sockets can now use external TCP sockets. Classic Bluetooth on WinRT and Bluetooth peripherals on Android are now both supported.

Qt Gui and 3Dqt3d

Qt GUI has gained a shader cache, that can cache compiled versions of OpenGL shader programs, and we have added support for Compute Shaders. The OpenGL paint engine does now work with OpenGL Core profiles as well.

An enormous amount of work has been done with Qt 3D. Together with the functionality we already had in Qt 5.8, we now have a fantastic 3D engine in Qt 5.9. You can find all the details in a separate blog post by our partner KDAB.

Qt QML and Quick

Quite a bit of work has been put into improving the QML and JS engine for Qt 5.9. We have added a completely rewritten garbage collector, offering better performance and reducing memory fragmentation in the JavaScript heap. The new collector also provides a better basis for further enhancements to our memory management in upcoming Qt versions.

Qt 5.9 also comes with a brand new QML caching infrastructure, offering similar benefits to our users — just like the commercially available Qt Quick Compiler, but in a much more transparent way. The new infrastructure has two modes of operation. In the default mode, the caching infrastructure creates a binary cache of your QML files at the first start-up of the application. Optionally, you can also pre-create that cache at application build time, achieving similar performance and startup time benefits as with the Qt Quick Compiler. Additionally, the new caching infrastructure does not bind your application to a specific patch level version of Qt, as the binary caches are versioned and will get regenerated if required.

Also, a lot of work to improve performance and reduce memory consumption has been done in the engine, making this a significant upgrade compared to our previous Qt 5.6 LTS release.

Qt Quick now makes use of the new OpenGL shader cache added in Qt GUI, improving application startup times. We added an image provider that can share image data between processes, and a new OpenVG backend, allowing it to run on hardware that only has 2D hardware acceleration support.

Qt Quick Controls 2 has added more new features than I can mention here, please have a look at the separate summary blog post, which links to all the details and blog posts on what has been added in Qt Quick Controls since Qt 5.7.

Qt Location and Positioning

For this release, Qt Location has received quite a few new features. We’ve added support for tilting and rotating maps, both through the APIs and through touch gestures. Stacking of maps has been improved, it’s now a lot easier to add overlay items to maps, and we improved the support for blending in copyright notices on the maps.

An entirely new plugin adds support for Mapbox, using their OpenGL based map rendering engine.


A couple of other visual improvements have also happened, like using lower resolution tiles to approximate tiles that are still missing at a higher zoom level until those are downloaded.

On iOS, we improved Qt Positioning, so that it now can collect data even when the application is in the background.

Other modules

Many other modules have also been updated. Most notably, Qt Webengine is now using Chromium 56. Qt Virtual Keyboard now supports external keyboard layouts and many other cool new features.


Qt Gamepad has graduated from Tech Preview status to being fully supported in Qt 5.9. We’ve also added Qt Remote Objects as a new module in Technology Preview status.

There have been significant changes to Qt Wayland that are described in a separate blog post.

Of course, Qt 5.9 also comes with a brand new version of Qt Creator with many great new features. The Qt Quick Designer now contains a built-in code editor, and we now have a completely rewritten the cmake integration. For further details, have a look at the separate blog.

Platform changes

Qt 5.9 adds support for two new platforms. It now supports QNX 7.0, the latest version of the QNX operating system. We have also added support for the INTEGRITY OS, details about this are again in a separate blog post.

Finally, we added support for compiling Qt in a size optimized mode (-Os on GCC), saving around 5-20% in binary size for the Qt libraries and your applications.


Finally, I’d like to thank all the people who have contributed to this release. While you can see and follow all the people contributing code through patches to our git repositories, a lot of additional work has happened more invisibly behind the scenes, for example by working on our CI and releasing infrastructure or helping to create collateral and content for the web pages.

I hope you’ll all enjoy this release. You can get it from the usual places, either through your Qt Account or from our download page. Please also don’t forget to give us your feedback, and write a bug report (if you should find one), so that we can improve the 5.9 series even further in upcoming patch releases.

The post Qt 5.9 released appeared first on Qt Blog.

Performance Improvements with Qt 5.9 LTS

Qt 5.9 LTS improves Qt Quick and QML performance significantly, especially with Linux on ARM. We have worked hard to improve the performance in multiple areas: within the QML engine, Qt Quick graphics, QML Compiler and in the Qt Quick Controls, to name some examples. Performance has improved significantly across all areas, with some items being several times faster than with our previous long-term supported release Qt 5.6 LTS.

We are regularly running several different kinds of performance tests to see how the various optimizations work across different platforms. Some of these results are visible at, while some tests have not been automated yet. Whenever possible, we are aiming to optimize the performance of all supported operating systems and CPU architectures. For readability and because Linux on ARM has been an area of particular focus with Qt 5.9 LTS, it is the one discussed in this post. Typically, the other platforms have received roughly similar improvements.

Qt Quick Application Startup Time

Startup time of a Qt Quick application is often critical in the embedded space. This is true for small single-process embedded systems, as well as for more complex multi-process devices. We have offered a commercial-only tool called the Qt Quick Compiler since Qt 5.3 to improve the startup time by leveraging the C++ compiler to compile QML into a normal C++ binary. Between Qt 5.6 LTS and Qt 5.9 LTS, the performance of the QML engine has improved with each new Qt release, resulting in improved application startup time. Qt 5.8 introduced QML caching, which makes second and subsequent runs of the applications to be faster. Qt 5.9 also offers a possibility to pre-populate the cache to reach improved performance already with the first run. With the Qt Quick Compiler, the first run is also already fast.


Each application has unique characteristics so the exact benefit in startup time for using Qt 5.9 LTS and/or the Qt Quick Compiler will vary. Typically, the more QML used, the bigger the improvement is. In Qt 5.9 LTS we offer two alternative options: the commercial-only Qt Quick Compiler and a new tool to populate the cache ahead-of-time, which is available for both open-source and commercial users. The performance and reduced startup time are in practice the same with both approaches in Qt 5.9 LTS.

When comparing the startup time for the same Qt Quick application with Qt 5.6 LTS without the Qt Quick Compiler to the startup time of Qt 5.9 LTS using the Qt Quick Compiler (or populated cache), the improvement is a whopping 60% on NXP i.MX6. When using the commercial-only Qt Quick Compiler of Qt 5.6 LTS the improvement in startup time is 54% (compared to Qt 5.6 LTS without the Qt Quick Compiler in use). Comparing the startup times of Qt 5.6 LTS and Qt 5.9 LTS when both are using the Qt Quick Compiler the improvement is 14% on NXP i.MX6.

The application used for the tests was the Qt Quick Controls 1 gallery and the tests were run with Linux on NXP i.MX6 and NVIDIA Tegra X1. We used the Controls 1 example because they are much heavier than Controls 2, thus better resembling a typical real-life Qt Quick application. For more measurements of Qt Quick application startup times, please check out the earlier blog post. For instructions to further optimize startup time of a Qt Quick application, please read the second post of our earlier fastboot blog series.

Qt Quick Controls Performance 

Qt 5.6 LTS features Qt Quick Controls 1 while Qt 5.9 LTS features the Qt Quick Controls 2 fully supported. The main design principle of Qt Quick Controls 2 has been performance, as can be seen already from the blog post announcing them. From the very beginning, the key focus area of the new Qt Quick Controls 2 has been for embedded devices and systems. However, these can equally well be used on all supported platforms. Compared to Qt Widgets or Qt Quick Controls 1, the key difference of Qt Quick Controls 2 is that they do not adapt to platform style. We do offer multiple different styles for Qt Quick Controls 2 and it is easy to make your own style as well. From an architectural viewpoint, the key difference of Qt Quick Controls 2 is that they leverage C++ for everything that can be done with C++ and offer just the QML API for applications to use.


As illustrated in the graph above, the performance improvement is huge (note: the higher the bar, the better the performance is). We used NXP i.MX6 running Linux for the measurements. For some of the controls the performance is 14x better than before, and on average the performance has been improved 6x comparing Qt 5.9 LTS with Qt Quick Controls 2 to Qt 5.6 LTS with Qt Quick Controls 1. To benefit from the improved performance, the application needs to be ported to use Qt Quick Controls 2. This is typically quite straightforward and Qt Quick Controls 2 offers most of the common controls. Before porting, please check the documentation, as some controls, such as TableView, are not currently available with Qt Quick Controls 2.

Shader Cache 

Qt 5.9 LTS introduces a new feature to cache OpenGL shaders to disk after the first run, as explained in the blog post introducing the shader cache. If your Qt Quick application is using OpenGL shaders, which is quite often the case, it will achieve a significant improvement in startup time compared to earlier versions of Qt. When comparing the performance of Qt 5.6 LTS to Qt 5.9 LTS using the same Qt Quick application with 10 shaders, we can see a significant improvement in the initialization time of the shaders. Some of the performance improvement observed in the measurement is due to the overall improvements in the graphics performance, but most of the improvement can be attributed to the new shader cache feature.


Qt 5.9 LTS is a whopping 7x faster than Qt 5.6 LTS on startup with the same exact Qt Quick application running the same hardware. Just like the previous measurements described in the blog post, this test has also been conducted using NXP i.MX6 running Linux. The performance improvement is dependent on the hardware and especially the GPU plays a major role. Based on our measurements there are significant improvements with every piece of hardware we have tested – including ones that implement cache feature already in the OpenGL driver.

Memory Footprint Improvements

In Qt 5.8 we introduced a new configuration system and made other improvements to reduce the binary size of the Qt framework libraries used for different applications. This was developed as part of the Qt Lite project, which focused specifically on reducing the application size. With Qt 5.9 LTS we have further polished and tuned the available configurations so that more and more different kinds of applications can reach their minimal Qt configuration. Reducing the size of a Qt 5.6 LTS application is possible mainly by just using the modules needed by the application and statically linking the binary. Because of dependencies within the Qt framework, the linker is not able to reach as small binary size as it is possible with Qt 5.9 LTS using the new configuration tool.


We used a simple, but non-trivial, Qt Quick application (samegame) to compare the needed binary size of the application itself as well as all the Qt libraries it needs. With Qt 5.6 LTS the application requires 24,5MB when linking dynamically. Using static linking, the size is reduced to 13,8MB (still using Qt 5.6 LTS). Leveraging the new configuration tool in Qt 5.9 LTS and with other Qt Lite improvements, the exact same application only needs 5,4MB when static linking is used. Percentage-wise, the Qt 5.9 LTS binary size of the application is 61% smaller than the same application with Qt 5.6 LTS and static linking – without losing any functionality or making any changes to the application.

Improvement in JavaScript Performance 

With the improvements in the QML engine in Qt 5.9 LTS the performance of JavaScript execution has also improved. If the Qt Quick application leverages JavaScript, there is a huge improvement in performance compared to Qt 5.6 LTS, especially on 64-bit ARM. One example of heavily leveraging JavaScript is using three.js on top of Canvas 3D, and smaller amounts of JavaScript are often used in Qt Quick applications.


The measurements are done with v8-bench, which can be found in the qtdeclarative repository. Additional measurements are available at With the v8-bench performance benchmark results of Qt 5.6 LTS compared to Qt 5.9 LTS, the improvement on 32-bit ARM is 16%, but on 64-bit ARM the improvement is a whopping 302% (i.e. 4x improvement). The reasons for the huge improvements are that Qt 5.9 LTS fully supports 64-bit ARM processors combined with the improvements in the QML engine.

Overall Qt Quick Performance Improvements 

The examples above are just some of the highlights from many improvements we have done to the performance of Qt Quick in Qt 5.9 LTS. We have tuned multiple individual areas and optimized the execution paths within the Qt framework. It is important to note that we have also worked hard not to regress in any areas. To avoid regressions, we are regularly running a comprehensive Qt Quick benchmark suite called Qmlbench. With the Qmlbench tool we can see the performance of the most commonly used Qt Quick functionality as well as the functionality that is used less frequently. For more details, please review the thorough explanation of how we are using Qmlbench to avoid regressions.


When comparing Qt 5.6 LTS and Qt 5.9 LTS in the same environment with the comprehensive Qmlbench measurements, we can see  that some areas improved up to 130% as shown in the graph above. Especially layout and complex text performance has improved drastically. The average improvement of Qt 5.9 LTS compared to Qt 5.6 LTS in all Qmlbench tests is 14% (measured on Linux). Despite which functionality is used, the improvement in performance of a Qt Quick application running Qt 5.9 LTS compared to Qt 5.6 LTS is clear and tangible for most applications.


In this blog post, I summarized some of the multiple performance improvements available with Qt 5.9 LTS. Compared to Qt 5.6 LTS, the performance of the same application running on Qt 5.9 LTS is significantly higher. Without making any changes to the application, except for compiling it for the new Qt 5.9 LTS, the performance is significantly improved. Ranging from improved application startup time and smaller footprint through to increased graphics performance, Qt 5.9 LTS is a major step forward performance-wise. Taking some of the new features, such as Qt Quick Controls 2, into use even furthers the performance improvements available with Qt 5.9 LTS.

Interested in taking a closer look? Qt 5.9.0 has been released today. You can get it with your online installer, from the Qt Account or from the Qt Downloads page (for open-source users).

For more details of Qt 5.9 LTS, please check the Qt 5.9 LTS release blog post.


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

Ready-made UI controls with Qt Quick Controls 2 – A summary

Designing UIs with buttons, switches, dials, sliders and other UI controls is made easy with Qt Quick Controls and QML. Qt Quick Controls provides ready-made UI controls that speed up the creation of great looking user interfaces. Qt Quick Controls has a selection of built-in styles based on various design guidelines allowing you to create UIs that are familiar to your end-users.  A lot has happened since Qt 5.7, where we introduced the new UI controls focusing on embedded systems and mobile, and the purpose of this blog is to give you a summary of what has happened and provide links to content we have created for the last three releases so that you can gain a better understanding of how the Qt Quick Controls can support your project.

Qt 5.7 — Qt Quick Controls 2 launch

In Qt 5.7 we introduced the new Qt Quick Controls 2 which were built from the ground up to improve the performance allowing us to target embedded systems and mobile as well as desktop applications.

Release video

You can read the release blog for Qt Quick Controls 2.0 – a new beginning.

Qt 5.8 — Focus on sought-after desktop features

In 5.8 the focus was back on improving some of the sought-after desktop features such as hover effects, system themes, and experimental native platform types to name a few.

Check out the release blog for the Qt Quick Controls 2.1.

Watch the on-demand webinar “Tips & Trick with Qt Quick Controls 2.1”

Qt 5.9 — Stability, performance, and multi-touch

The focus for the Qt 5.9 release has been to improve stability and performance and create the next go-to release of Qt with long-term support (LTS). On the QML engine, there have been a lot of improvements directly enhancing the performance and stability of the Qt Quick Controls. We have also added new features such as support for multi-touch. To read more about the new features you can get an overview on the wiki page.

Qt 5.10 and beyond

The Qt Quick Controls 2 can be used as is or you can customize them through defining your style in QML, but what if you want to have the Qt Quick Controls styled by a graphic designer? We are currently researching and developing a way where you can use design software such as Photoshop, Illustrator and so on to style the controls without coding QML. With this approach designers and developers can work together on creating stunning user interfaces.


Check out the video from Embedded World showing off the new features:


Also, read the blog post regarding the project and our plans moving forwards.

With that, I hope that this blog served as a good summary of what has happened with Qt Quick Controls 2 since its release with Qt 5.7 and there is also much more information on Qt Quick Controls available on our blog, our YouTube channel and in our documentation. If you are interested in using the Qt Quick Controls 2 for your next project, you can always contact us if you need support on how to get started.

The post Ready-made UI controls with Qt Quick Controls 2 – A summary appeared first on Qt Blog.

Multiple UI processes with Qt Wayland – A summary

Creating multi-process UIs is a requirement for a broad range of systems across many industries, and there are a variety of use cases available. Everything from fully leveraging your hardware in a digital automotive cockpit — unifying the user experience across all screens on a single SoC, through to separating out critical safety features in medical devices and ensuring safe third-party updates for set-top boxes and digital TVs. Qt Wayland helps you create multi-process user interfaces which support complex architectures.

Recently, we have put a lot of effort into Qt Wayland and the purpose of this blog is to provide a summary of all the content pieces that have been created in recent times. We hope this may entice your interest to add a window compositing system in your next project.

Multi-screen demo for Automotive

At Embedded World 2017 one of our showcases was a multi-screen demo featuring a digital instrument cluster and infotainment system (IVI). To create the multi-process architecture, it uses the application manager based on Qt Wayland in the Qt Automotive Suite. This demo gives you a good idea of how a system with multiple UI processes can look.

Qt Wayland for Agriculture with CLAAS E-Systems

CLAAS E-Systems, part of the CLAAS Group, which is one of the leading manufacturers of harvesters and tractors, quickly adopted Qt Wayland. We have been in contact with Andreas Cord-Landwehr from CLAAS, who stressed that the complexity for automotive was nothing compared to the complexity that he experiences within the field of agriculture. He was more than willing to write a blog to tell his story of how Qt Wayland allowed them to improve their UIs and UX for their machinery. Read the blog to learn more about his experiences with Qt Wayland. 

Creating devices with multiple UI processes using Wayland

One of our main developers for Qt Wayland, Johan Helsing, wrote a blog post in conjunction with our release of the Qt Wayland Compositor API in 5.8, where he explained some of the benefits of creating multi-process user interfaces, as well as why and how it can support your project. He also created a video tutorial on how to create a compositor. Read the blog and watch the tutorial and also check out his on-demand webinar — Creating Devices with multiple UI processes.

Qt from git on the Tinkerboard (with Wayland)

Laszlo Agocs, one of our senior software engineers, conducted a test using an Asus Tinkerboard and set up the latest Qt base and qtdeclarative from the dev branch and tested out Qt Wayland for window compositing. Read more about the project and the results.

There are also more blog posts on this topic available. Contact us if you need support or consulting on how to get started.

The post Multiple UI processes with Qt Wayland – A summary appeared first on Qt Blog.

Qt Lite in Qt 5.9 LTS

by Nils Christian Flinder Roscher-Nielsen (Qt Blog)

Qt Lite has been our project name for multiple efforts done to approach to a more scalable Qt version. We introduced this first in Qt 5.8, earlier this year, and are extremely happy to see all the use cases and new opportunities this has unlocked for Qt. It is now far easier than before to build a small and tailored version of Qt for your specific need.

We have added a lot of new configuration options in Qt 5.9 LTS, and updated the corresponding Qt Configuration UI Tool to take this into account.  The configuration tool list all the options available, and provides simple and easy access to all the new configuration options. This way, you do not have to learn all the ins and outs of each module, to generate a meaningful and optimized version of that module. For the time being, the Configuration UI Tool is a commercial only tool, that adds value for our Device Creation customers.

There are hundreds of individual configuration options, ranging from major features like OpenGL support, to minor details in Qt. Qt Lite covers features in all our core libraries, Networking, SQL, Qt GUI, Qt QML, Qt Quick, XML, Widgets, Connectivity, Qt Gamepad, Location and Positioning, Multimedia, Sensors, Serialbus, Wayland Client and Compositor, Bluetooth, XML Patterns, as well as Qt WebEngine, and more. Qt Lite thus allows you to disable features that are not used in your application, even though you still want other features available in the modules they have been implemented. Moving away from a completely monolithic approach has been very beneficial, and we hope this can continue to benefit all our users.

One example of this is the implementation of Samegame, a non trivial Qt Quick based game. In Qt 5.6 LTS, the statically linked application and libraries all of 13.8MB, but using Qt Lite configuration options, we are able to create a more than 60% smaller deployable binary with Qt 5.9 LTS.


As Qt continues to grow, and add more features, we see this as an important mechanism of maintaining a framework that will fit with the needs of the embedded industry. In line with this, Qt 5.9 is the first release in which we officially support the new iMX7 architecture from NXP; and without OpenGL and targeted at the wearables market Qt lite provides an excellent way of deploying to this target.

Qt Lite has been happening along two axes, one part focusing on the configuration system of Qt, and the other making other improvements to Qt to make it perform better in a constrained environment.

To that end we are also adding improvements such as the better utilization of optimization flags. Release builds can achieve a significant further reduction in size from 5-20 percent, by utilizing -Os (with gcc/clang) or -O1 (MSVC). This is enabled with the Qt configuration flag -optimize-size.

Together with the work we do to optimize Qt Quick code, the improvements of Qt Quick Controls for embedded targets, the new OpenVG back end for the improved Scene Graph and all the other efforts in Qt 5.9, these improvements make Qt 5.9 the best choice for any new Device Creation project. And on top of that, it will be supported for a long time, as an LTS release. We hope to see all the cool things that you have been doing with it, and that we can make your product development faster, simpler and more fun. If you want to get started with Qt Lite in 5.9LTS, do not hesitate to contact us if you need support or consulting.

The post Qt Lite in Qt 5.9 LTS appeared first on Qt Blog.

Swift 4.0 RC2: Now Available

A Release Candiate for Swift 4.0 is now available for download. Read on for more information and download instructions.

Swift 4.0 RC2 is now available from our releases page. This release includes:

  • Support for message carbons (XEP-0280)
  • Trellis mode enabled as a default feature, allowing several tiled chats windows to be shown at once
  • New chat theme including a new font
  • Redesigned keyword highlighting
  • Improved spell checker support on Linux
  • Support for automatic software updates on macOS
  • Support for unicode emojis on macOS
  • And assorted smaller features and usability enhancements

Please email ( or tweet (@swift_im) any feedback you have to help us further improve Swift.

Cutelyst 1.7.0 released! WebSocket support added.

Cutelyst the Qt / C++11 web framework just got another important release.

WebSocket support is probably a key feature to have on a modern web framework, Perl Catalyst doesn't look like it wasn't designed with it in mind, the way I found to do WS there wasn't intuitive.

Qt has WebSocket support via QWebSockets module, which includes client and server implementation, and I have used it for a few jobs due lack of support inside Cutelyst. While looking at it's implementation I realized that it wouldn't fit into Cutelyst, and it even had a TODO due a blocking call, so no go.

I've looked then at uWSGI implementation and while it is far from being RFC compliant or even usable (IMO) the parser was much simpler, but it required that all data was available to parse. Since messages can be split into frames (really 63bits to address payload was probably not enough) and each frame has a bit to know if the message is over, which uWSGI simply discards, thus any fragmented message can't be merged back.

WebSockets in Cutelyst have an API closer to what QWebSocket has, but since we are a web framework we have more control over things, first on your websocket endpoint you must call:


If the return is false just return from the method to ignore the request or it might be the case that you want the same path to show a chat HTML page, this can happen if the client didn't sent the proper headers or if the Engine backend/protocol doesn't support WebSockets. If true you can connect to the Request object and get notified about pong, close, binary and text (UTF-8) messages and frames, a simple usage is like:

connect(req, &Request::webSocketTextMessage, [=] (const QString &msg) {

  qDebug() << "Got text msg" << msg;



This will work as a Echo server, the signals also include Cutelyst::Context in the case you are connecting to a slot.

Cutelyst implementation is non-blocking, a little faster than QWebSockets, uses less memory and passes all tests, it doesn't support compression yet.

systemd socket activation support was added, this is another very cool feature although it's still missing a way to die the application on idle. On my tests with systemd socket activation, Cutelyst started so fast that the first request that starts it takes only twice the time it would take if Cutelyst was already running.

This release also include:

  • Fixes for using cutelyst-wsgi talking FastCGI to Apache
  • Workaround QLocalServer closing down when an accept fail (very common when used on prefork/threaded servers)
  • Fixed when using cutelyst-wsgi on threaded mode, POST requests would use the same buffer corrupting or crashing.
  • A few other fixes.

Due WebSockets plans for Cutelyst 2 are taking shape, but I'll probably try to add HTTP2 support first since the multiplexing part is might make Cutelyst Engine quite complex.

Have fun

Qbs 1.8 released

Qbs (pronounced “Cubes”) is The Qt Company’s latest build tool, which is planned to be the replacement for qmake in the Qt 6 build system. In addition to its use within Qt, for our customers Qbs will also provide faster build times coupled with a rich feature set in order to reduce build engineering complexity and decrease time to market.

Today, we’re pleased to announce the release of Qbs 1.8! This is primarily a stability-focused release which paves the way for some powerful new features coming in a few months with 1.9.

What’s new?

In addition to the usual bug fixes and performance enhancements, this release provides the following new features:

New Platforms and Toolchains

Qbs now has initial support for building applications for the QNX real-time operating system. We support several versions of the official QNX SDK: SDP 6.5, SDP 6.6, and the recently released SDP 7.0 with support for development on macOS. We may also extend support to additional toolchains in the future, like Intel ICC.

There is also basic support for building FreeBSD applications. While it has always been possible to build for FreeBSD, it is now a recognized target and therefore projects targeting that platform build without any additional environment configuration.

Android Support

Single-architecture Android builds are now handled more gracefully. This means Qbs will be usable in Qt Creator when building for Android, and dependencies on Qt modules should work too. This moves us closer to functional Android support, although there are still many tasks left to do, including support for Clang/LLVM from the Android NDK.

Language Improvements

A new syntax for accessing module properties in JavaScript extensions has been introduced. You can now use the syntax product.modulename.propertyname to access a module property of a product or artifact, so that you get consistent property access syntax between Qbs files and JavaScript files. For example, product.moduleProperty("cpp", "compilerFlags") should now be written as product.cpp.compilerFlags. For module authors, note that the module object might be undefined if the module is not loaded in the given product’s context, so you should check that it is a truthy value before using it (for example: !!product.cpp). Note that the old moduleProperty() function will still be available but its use is discouraged.

Read-only properties are now supported. Declaring a property with the readonly modifier will now cause an error to be emitted if an attempt is made to set a value on it.

Probe items are now allowed within Project items, which should allow more logical project structures for Probes that really aren’t dependent on a particular product’s context.

The loadFile() and loadExtension() function have been replaced by require() and will be deprecated in a future release.


Qbs can now be run without a profile. This is a small but enabling change which follows from our new strategy that favors automatic detection and Probes over the use of pre-created profiles in order to push an “it just works” experience. This change makes it easier for new users to get started with Qbs, while also making development environment maintenance easier by reducing reliance on external data that requires manual setup and is likely to become outdated over time. You can of course continue to use profiles just like before, however invoking ‘qbs’ from the command line will now automatically build for the current host platform using the best available toolchain and settings unless a default profile is set. You can also explicitly use the “null” profile by specifying profile:none on the command line.

Currently this has no effect on how projects are built in Qt Creator; Qbs projects in the IDE always use an automatically generated profile which sets a minimal set of properties corresponding to the selected kit.

Other new features

  • Added a new qbs-create-project tool which can help to automatically generate qbs project files from an arbitrary directory structure. This can be a useful starting point when migrating from other build tools such as qmake or CMake.
  • The means to easily combine source files for the C language family in order to support “amalgamation builds”.
  • qbs-setup-toolchains adds support for Visual C++ Build Tools.
  • Better line and column information in error reporting.
  • PkgConfigProbe now provides a higher level API by parsing the raw compiler and linker flags output from pkg-config. There are new properties individually listing the preprocessor defines, include paths, compiler flags, and so on.
  • Fixes to change tracking and general handling of manifests in the Java module.
  • It should now be possible to build qbs itself statically, as the scanner plugins have been fixed to be compatible with static builds.

That’s all for now. The Xcode generator was unfortunately delayed again and thefore is not present in 1.8, but 1.9 will be quite a monumental release bringing some very significant new features around multiplexing and dependency handling. Stay tuned!

Breaking Changes

There are a few breaking changes of note in this release:

First, the cpp.linkerFlags property no longer accepts pre-escaped values. That is, you should not escape linker flags passed to the cpp.linkerFlags property with the -Wl, or -Xlinker escape sequences, as Qbs will automatically apply them based on whether the linker in use is the compiler driver (like clang++ or g++) or the system linker (like ld). This has generated a warning for the past couple of releases and we encourage you to migrate your build scripts if you haven’t already, as using -Wl, or -Xlinker in cpp.linkerFlags will now lead to a double-escape and a linker error.

Second, all files that are part of a bundle on Apple platforms like macOS and iOS are now tagged with “bundle.content”. If you want to install the files that constitute a bundle, this is the one and only tag that your installation Group’s fileTagsFilter should reference. Previous methods of installing bundles based on the file tags of the individual files that constitute them are not guaranteed to work.

Last, the base directory for source files has changed from the product source directory to the parent directory of the file where the files are listed. The old behavior was unintuitive and usually not what users want when groups are pulled in from other files such as modules.

Try It!

The Open Source version is available on the download page, and you can find commercially licensed packages on the Qt Account Portal. Please post issues in our bug tracker. You can also find us on IRC in #qbs on, and on the mailing list. The documentation and wiki are also great places to get started.

Qbs is also available on a number of packaging systems (Chocolatey, MacPorts, Homebrew) and updated on each release by the Qbs development team. It can also be installed through the native package management system on a number of Linux distributions including but not limited to Debian, Ubuntu, and Arch Linux.

Qbs 1.8 is also included in Qt Creator 4.3, which was released earlier this week.

The post Qbs 1.8 released appeared first on Qt Blog.

Qt Lite

Qt Lite is an initiative driven by The Qt Company striving for smaller and leaner Qt builds. It utilizes the new configuration system introduced with Qt 5.8 to create custom builds stripped of features or classes that aren’t needed for a given application. Focus is mostly on Embedded Linux with the goal of making Qt a feasible option … Continue reading Qt Lite

What makes for good animation?

In the beginning there was …


That’s how things start, right? And in the beginning there were punch cards. The UI was rudimentary direct machine language, so we could say there was no UI. So let there be light!

In very simplistic terms that was a screen where one could type text (using a keyboard) and see the same text on the screen … maybe get some feedback on the results of a command. And let the animation begin!

The post What makes for good animation? appeared first on KDAB.

Device detection in Qt for Device Creation 5.9

Qt for Device Creation provides ready disk images for a variety of devices. When you flash it to a device, start enterprise Qt Creator and plug the device in via USB, it will be detected automatically. You are ready to run, debug and profile your applications right on the device. From a user’s point of view the green marker for a ready device just appears.


But how do we actually see the device? There have been changes here for 5.9 and in this post I’ll discuss what we ended up doing and why.

How things used to be

Previous versions of Qt for Device Creation use Android Debug Bridge (ADB) for the device discovery. As you can guess from the name, it’s the same component that is used in the development of Android applications. It was a natural choice early in the development of the Boot2Qt when Android was a supported platform along with embedded Linux. But nowadays we focus on embedded Linux only. (In Device Creation with the device images, Qt can of course still be used to build applications on Android.)

Due to requiring Google’s USB drivers, ADB has made installing more complicated than desired for our users on Windows. And when they jumped through the hoops, they could end up with a different version than we tested against. There’s also the risk of mixups with Android development environments, who may include their own versions of ADB. There were also some things missing, which required working around inside our Qt Creator integration.

Recognizing USB devices

So to avoid those issues we decided to decided to write our own debug bridge, which we without extraneous imagination called QDB. It looks for Boot2Qt devices in a similar way as the purpose of other USB devices is discovered. When a device is enumerated in the universal serial bus, it describes its class, subclass and protocol. For example for my mouse the command lsusb -v reveals:

      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      2 Mouse

There is a vendor-defined class 255. We have picked a subclass and protocol inside that which our devices use, thus allowing QDB to find them. Finding them is of course not enough, since there needs to a way to transfer data between the host computer and the device.

Network over USB

ADB implements file transfers and port forwards. It transfers the data over the USB connection using its own protocol. One obvious option would have been to do the same thing. That would have been reinventing the wheel, as was quickly pointed out by many. There was also a second place where duplication of effort to accomplish the same thing was happening. The Boot2Qt plugin for Qt Creator was implementing support for running, debugging and profiling applications with ADB. But Qt Creator also supports these things with any Linux device over SSH through the RemoteLinux plugin. If we were able to use SSH, all of that duplication could be gotten rid of (after the support window for older Qt for Device Creation releases runs out).

Linux allows a device to present itself as an USB Ethernet adapter with the kernel module usb_f_rndis. The device then shows up as a network card in both Linux and Windows. This way we can have a network connection between the host computer and the device, which allows the use of SSH and thus the desired reuse. And apart from Qt Creator activity, the user can also use regular SSH to connect to the device. It has a properly resizing terminal, unlike adb shell! All the other things you might do over the network also become possible, even if the embedded device has no Ethernet socket.

But there’s something we glossed over. Networks don’t configure themselves. If the user would need to set the right IP address and subnet mask on both the computer and the device, then we certainly wouldn’t meet the bar of just plugging in the device and being ready to go.

Configuring the network

Now despite what I just said there actually are efforts for networks to configure themselves. Under the umbrella term zeroconf there are two things of interest in particular: link-local IPv4 addresses as specified in RFC 3927 and mDNS/DNS-SD, which allows finding out the addresses of devices in the network. For a while we tried to use these to accomplish the configuration of the network. However, getting the host computer to actually use link-local addresses for our network adapter proved fiddly and even if it worked there was a bit too long delay. The connection only works after both the host computer and device have gotten their IP which wasn’t predictable. I hope we will be able to revisit mDNS/DNS-SD at some point, because it might allow us to provide device discovery when devices are connected over Ethernet instead of USB, but for now zeroconf required too much configuration.

Another thing which we looked at was using IPv6 link-local addresses. Unlike their IPv4 cousin they are part of the protocol and always available, which would eliminate the delays and configuration burden. Here the downside is that they are a bit more local to the link. An IPv4 link-local IP is from the block and you can just connect to it regularly. IPv6 versions use the prefix fe80::/10, but they also require a “scope ID” to describe the network adapter to use. I’d rather not write

ssh user@fe80::2864:3dff:fe98:9b3a%enp0s20f0u4u4u3

That’s superficial, but there was also a more important issue: All the tools would need to support IPv6 addresses and giving these scope IDs. GDB – which we use for debugging – didn’t.

Back to the drawing board. The simplest approach would be picking up a fixed IP address for the devices. That has two issues. First, you can’t connect more than one device. Second, the fixed IP address might already be in use on the host computer. We ended up using the following approach to circumvent these problems: The same process that recognizes the USB devices knows a list of candidate network configurations in the private use IPv4 ranges. When a new device is connected, it looks at the networks the host computer currently has and then picks a candidate that doesn’t conflict. The device is told the configuration, sets its own IP address accordingly and then acts as a DHCP server that provides an IP for the host computer.

After this process is done, the host computer and device have matching network configurations, Qt Creator knows the IP of the device and everything is ready. If you connect a second device, a different candidate configuration is picked, since the first one is already in use. The DHCP server is disabled when the device is disconnected, because otherwise host computer could get an IP from a previous configuration when it is connected again.

The post Device detection in Qt for Device Creation 5.9 appeared first on Qt Blog.

What’s new in Qt 3D with Qt 5.9?

by Sean Harmer, KDAB [Qt Service Partner] (Qt Blog)

I am pleased to announce that there are lots of new goodies coming along with Qt 3D as part of the Qt 5.9.0 release as well as the usual round of bug fixes. Engineers from KDAB and The Qt Company have been hard at work over the last months (and will be for some time to come) adding in some of the most frequently requested features. In this article, we will give a brief overview of some of the bigger features coming your way.

Using Qt Quick within Qt 3D

A very common request that we have had since we first released Qt 3D is to have the ability to embed Qt Quick scenes within a Qt 3D application. The use cases for this are wide ranging, but a typical example is to place a 2D user interface onto the surface of some planar piece of geometry in your 3D world to simulate an “in-3D-universe-control-panel”. As VR/AR become more popular, this use case is likely to increase in importance.

I’m happy to say that embedding Qt Quick into a Qt 3D scene is now easily possible. Even better, it is possible to interact with such 2D UIs within the 3D world! The Scene2D QML Example shows how to use the new Scene2D type to render Qt Quick to a texture, apply it to a 3D object, and ensure that events are forwarded to the QQuickItems to allow interactivity.




In short, we can render a Qt Quick 2 scene into a texture with Scene2D and register it to receive events from a Qt 3D entity called “cube”:

Scene2D {
    id: qmlTexture
    output: RenderTargetOutput {
        attachmentPoint: RenderTargetOutput.Color0
        texture: Texture2D { id: offscreenTexture }
    entities: [ cube ]
    Item {
        id: customQtQuickStuff

This takes care of rendering the texture. Using it on an Entity is simply a case of applying the resulting texture which can be done with the TextureMaterial:

Entity {
    id: cube

    components: [cubeTransform, cubeMaterial, cubeMesh, cubePicker]

    property real rotationAngle: 0

    Transform {
        id: cubeTransform
        translation: Qt.vector3d(2, 0, 10)
        scale3D: Qt.vector3d(1, 4, 1)
        rotation: fromAxisAndAngle(Qt.vector3d(0,1,0), cube.rotationAngle)

    CuboidMesh {
        id: cubeMesh
    TextureMaterial {
        id: cubeMaterial
        texture: offscreenTexture
    ObjectPicker {...}

The ObjectPicker in the above code is picked up by the Scene2D’s “entities” property and used as a source for events.

The counterpart to Scene2D is Scene3D which allows embedding a Qt 3D scene inside of a Qt Quick 2D UI. Hopefully, in the future, we will be able to get a seamless blend between Qt Quick and Qt 3D.

Physics Based Rendering

Modern rendering engines have largely adopted Physics Based Rendering (PBR) to improve the visual appearance of their results and to make it easier for artists to get predictable results. PBR encompasses a family of techniques but essentially says that rendering should be more physically rigorous when shading than older ad hoc lighting models. For more information and background on PBR please take a look at this talk from Qt Con 2016.

pbr-metal-rough powerup-qt3d-pbr

New to Qt 3D in Qt 5.9 are two new materials: QMetalRoughMaterial and QTexturedMetalRoughMaterial which implement a PBR algorithm with Blinn-Phong specular highlights. There is also a new light type QEnvironmentLight that can be used in conjunction with the above materials to provide nice environmental reflections and image based lighting (IBL) as shown below.

The source code for the above examples are available at KDAB’s github.

Key Frame Animations

Qt Quick has long had support for easily specifying animations using an intuitive API. This can be used along with Qt 3D to animate properties. A frequent request from digital content creators is for support of key frame animations. Also, given the highly threaded architecture of Qt 3D, it would be nice if we could find a way to improve how animations scale compared to having them evaluated by the main thread. The technology preview of the new Qt3D Animation module achieves exactly this.

Whereas the Qt Quick animation API (and the QPropertyAnimation API in C++) specify an animation curve between the start and end times, when using key frame animations we instead specify the property values at specific times known as key frames. To evaluate the animation at times that do not exactly correspond to key frames we use interpolation/extrapolation. For now, Qt 3D Animation implements a Bezier curve interpolation, but we will expand this with other types for Qt 5.10. However, with the key frames being Bezier curve control points, it is already possible to achieve a wide range of animation curves.

The animation curves are specified using QAbstractAnimationClip which boils down doing it programmatically with QAnimationClip or loading baked animation data exported from a digital content creation (DCC) tool with QAnimationClipLoader. Qt 3D provides a handy addon for Blender to export the animation data of objects into the json format consumed by Qt 3D.



The actual playback of animation data is handled by a new QComponent subclass called QClipAnimator. As with all other QComponents, the clip animator must be aggregated by an entity to give behaviour to the entity. In addition to the raw animation data, the clip animator also needs a way to specify which properties of which target objects should be updated by the animation. This is done with the QChannelMapper and QChannelMapping classes. Please take a look at this blog post showing a simple application that animates a character using the Qt 3D Animation framework. The source code for this can be found at KDAB’s github.

Entity {
    id: cube

    components: [
        Transform { id: cubeTransform },
        Mesh { source: "qrc:/assets/egg/egg.obj" },
        TexturedMetalRoughMaterial { ... },
        ObjectPicker { onClicked: animator.running = true },
        ClipAnimator {
            id: animator
            loops: 3
            clip: AnimationClipLoader { source: "qrc:/jumpinganimation.json" }
            channelMapper: ChannelMapper {
                mappings: [
                    ChannelMapping { channelName: "Location"; target: cubeTransform; property: "translation" },
                    ChannelMapping { channelName: "Rotation"; target: cubeTransform; property: "rotation" },
                    ChannelMapping { channelName: "Scale"; target: cubeTransform; property: "scale3D" }

The clip animator, animation data, and channel mapper types represent different concepts which are all merged in the familiar Qt Quick and QPropertyAnimation APIs. Separating these out allows us more control and reuse of the individual parts but we will look at adding some convenience API on top for common use cases.

The QClipAnimator class simply plays back a single animation clip. But what if we wish to combine multiple animation clips? We could drop down a level and craft some new animation data that combines the clips but that’s tedious, error prone and doesn’t work well when changing how we combine the clips at a high frequency. Enter QBlendedClipAnimator. Instead of a single animation clip, the API of a blended clip animator takes a pointer to the root of an animation blend tree – a data structure describing how an arbitrary number of animation clips can be blended together. The blend tree consists of leaf nodes representing animation clips and interior nodes representing blending operations such as linear interpolation or additive blending. For more information on blend trees, please take a look at the Qt 3D Overview documentation.

In order to have performance that scales, the Qt 3D Animation framework evaluates the animation curves on the thread pool utilised by the Qt 3D backend. This allows us to scale across as many CPU cores as are made available. Also, it is often the case that the object tree on the main frontend thread doesn’t need to know or care about the intermediate property updates during an animation. Therefore by default, only the final change from an animation is sent to the frontend objects. If you do need the intermediate values, perhaps because you have property bindings depending upon them, then you can subscribe to them via the new QNode::defaultPropertyTrackingMode. The default behaviour is consistent with the Qt Quick Animator types.

In addition to key frame animations, the Qt 3D Animation module introduces initial support for morph target animations that allow blending mesh geometries between a set of specified target shapes. The blending can be controlled via the above key frame animations. This is likely to be moved into the Qt3D Render module once we flesh out the support a little more.

Level of Detail

When building larger 3D scenes it can be useful to only render the full resolution geometry with high-resolution textures when the object is close enough to the camera to justify it. When the objects are farther away, and the projected screen size is small, it makes sense to use lower fidelity models, textures, and perhaps even shaders to reduce the overall rendering cost and therefore increase performance. Qt 5.9 introduces the QLevelOfDetailand QLevelOfDetailSwitch components to enable this.

The QLevelOfDetail component allows you to set an array of the camera to object distance thresholds or projected screen pixel sizes. As these thresholds are reached, the component adjusts its currentIndex property to match that of the corresponding threshold. You can bind to this property (or connect to its notification signal) to do whatever you like in response. For example, use a loader to load a different mesh, set smaller textures, use a simpler material or shader. It’s up to you.

Entity {
    components: [
        CylinderMesh {
            radius: 1
            length: 3
            rings: 2
            slices: sliceValues[lod.currentIndex]
            property var sliceValues: [20, 10, 6, 4]
        Transform {
            rotation: fromAxisAndAngle(Qt.vector3d(1, 0, 0), 45)
        PhongMaterial {
            diffuse: "lightgreen"
        LevelOfDetail {
            id: lod
            camera: camera
            thresholds: [1000, 600, 300, 180]
            thresholdType: LevelOfDetail.ProjectedScreenPixelSizeThreshold
            volumeOverride: lod.createBoundingSphere(Qt.vector3d(0, 0, 0), 2.0)

The QLevelOfDetailSwitch component works in a similar way but implements a common use case where the children of the Entity upon which it is aggregated are all disabled except for the one matching the currentIndex property. This allows you to quickly and easily get a level of detail system into your application.

Entity {
    components: [
        LevelOfDetailSwitch {
            camera: camera
            thresholds: [20, 35, 50]
            thresholdType: LevelOfDetail.DistanceToCameraThreshold

    HighDetailEntity { enabled: false }
    MediumDetailEntity { enabled: false }
    LowDetailEntity { enabled: false }

For the QML users, there is also a LevelOfDetailLoader which, as its name suggests, dynamically loads custom QML components as the level of detail thresholds are reached.

LevelOfDetailLoader {
    id: lodLoader
    camera: camera
    thresholds: [20, 35, 50]
    thresholdType: LevelOfDetail.DistanceToCameraThreshold
    volumeOverride: lodLoader.createBoundingSphere(Qt.vector3d(0, 0, 0), -1)
    sources: ["qrc:/HighDetailEntity.qml", "qrc:/MediumDetailEntity.qml", "qrc:/LowDetailEntity.qml"]

Text Support

Although we have support for embedding Qt 3D within Qt Quick and vice versa, it is still nice to be able to directly use textual content within your 3D virtual worlds. Qt 5.9 introduces 2 ways to do this (beyond Scene2D).

First, there is 2D planar text implemented with distance fields just like the default text rendering in Qt Quick. This is done by way of the QText2DEntity

Text2DEntity {
    id: text
    text: "Hello World"
    width: 20
    height: 10

This can be positioned freely in 3D space just like any other entity, and so this becomes a first class citizen of your 3D world.

For those of you that want solid, extruded, 3-dimensional text, there is the QExtrudedTextGeometry class. Or for even more convenience, there is the analogous QExtrudedTextMesh which is a subclass of the QGeometryRenderer component and can, therefore, be directly aggregated by an entity.

auto *text = new Qt3DCore::QEntity(root);

auto *textTransform = new Qt3DCore::QTransform();

auto *textMesh = new Qt3DExtras::QExtrudedTextMesh();
QFont font(family, 32, -1, false);

auto *textMaterial = new Qt3DExtras::QPhongMaterial(root);
textMaterial->setDiffuse(QColor(111, 150, 255));



If you need any other kinds of text support in Qt 3D please let us know.


I hope that this has given you a good overview of the new features coming to Qt 3D with Qt 5.9. We think that you will find them useful in building ever more ambitious 3D projects with Qt. We have even more surprises in the pipeline for Qt 5.10 so watch this space.

The post What’s new in Qt 3D with Qt 5.9? appeared first on Qt Blog.

Release 2.11.0: All Monetization Plugins Now Free, Plugin Trial & Firebase Qt Plugin

V-Play 2.11.0 adds many improvements to V-Play plugins:

  • All monetization plugins for in-app purchases and advertisements are now free to use in all licenses, including the Personal License!
  • You can test all other plugins (for analytics, push notifications, crash reporting, beta distribution) in your free license too.
  • It is a lot easier now to add these plugins to your projects with the new plugin templates.
  • The Google Firebase plugin is new – you can use it for user authentication and to access the Firebase Realtime Database.

Free Monetization Plugins for all V-Play Developers

Many developers ask us: “I’d like to earn money with my app/game, but can’t afford the Indie license as I’m doing this as a hobby. What can I do?”

We decided to make this decision easy. Starting with this V-Play release, you can use all monetization plugins for free, and you don’t need an Indie/Enterprise license to make money with your app or game!

The now-free monetization plugins include:

  • Soomla Plugin for cross-platform in-app purchases and virtual currencies
  • Advertisement plugins to show interstitial ads, banner ads and rewarded videos with Google AdMob and Chartboost

We don’t charge any revenue share, all the revenue you make is yours. And if your app is doing well and you’re earning more than $50,000 a year, the Indie license (which is $49 per month) is the right choice. The Indie license has a few additional benefits – you can:

  • Remove the V-Play Splash Screen.
  • Also use all the other plugins, such as those for advanced analytics, push notifications, crash reporting and beta distribution.
  • Get advanced email support.

To sum it up, the Indie license is for established companies who are already earning revenue. And for starting your app or game business, you can now use all the monetization options available in the higher-tier licenses.

How to Add a V-Play Plugin to your App or Game

When you create a new project, you can now choose the Plugin Application template. Open Qt Creator and choose “File / New File or Project”, then select Plugin Application in the V-Play Games or V-Play Apps section.

Then select the platforms you’d like to add the plugins for. The plugins are available for iOS & Android. There is a fallback functionality in place on Desktop platforms so your project still works when you call methods of the plugins. This allows you to do the main development on your PC, and for testing the plugin functionality you can run the project on iOS and Android:

You can then choose which of the plugins you’d like to add to your project:

Your project is now set up with all the correct plugin dependencies for Android & iOS automatically. This includes:

  • Setting up the .gradle file for Android.
  • Setting up the .plist file for iOS.
  • Setting up the .pro file to include the plugin libraries for iOS.

How Can I add a Plugin to an Existing Application?

If you have an existing V-Play application, follow these steps to include a plugin to your app or game.

Note: If you have an existing Qt application, you can also add V-Play Plugins to your app! See here how to do this.

In Qt Creator, choose “File / New File or Project” and choose either V-Play Games or V-Play Apps from Files and Classes. Select V-Play Plugin and press Choose.

You can now select the plugin you want to add, in this example we’ve chosen AdMob:


The AdMob item is now added to your project. The created item contains ready-to-use ad identifiers so you can try it quickly without having to create an own account. You can of course also change these to your ad ids. The created item looks like this:

import VPlayPlugins 1.0
import QtQuick 2.0
import VPlayApps 1.0 // only used for ListView with Plugin Overview and Example

 Add the following piece of code inside your main QML { } to display this example page.

 ItemWithAdMob {



Rectangle {
 anchors.fill: parent

 // Plugin Item
 AdMobBanner {
   id: adMobBanner
   adUnitId: "ca-app-pub-9155324456588158/9913032020" // replace with your AdMob adUnitId
   banner: AdMobBanner.Smart

   anchors.horizontalCenter: parent.horizontalCenter
   anchors.bottom: parent.bottom

 // Plugin Item
 AdMobInterstitial {
   id: interstitial
   adUnitId: "ca-app-pub-9155324456588158/9075427220" // replace with your AdMob adUnitId

 // AppListView for Plugin Overview and Example Usage
 AppListView {
 // example usage of the plugin, removed here for brevity ...


To use the item in your project, simply perform these steps:

  • Include the ItemWithAdMob (use the name you entered in the template before) in your main.qml file.
  • Modify the .pro file & .plist file for iOS usage. See the iOS integration guide for AdMob here.
  • Modify the the .gradle file for Android usage. See the Android integration guide for AdMob here.

How to Test All Plugins – New Plugin Trial

With this release, you can test all plugins that are included in the Indie & Enterprise license in your free license too. There are plugins for analytics, push notifications, crash reporting, beta distribution and more.

The full functionality of a plugin is available for testing. When you are calling a method from the plugin, for example AdMob::showInterstitial(), there is a dialog shown and a watermark in your application to notify you about the testing state of the plugin.

If you have purchased the Indie or Enterprise license, you can remove these notifications and fully use all plugins in your apps by creating a license key. As the monetization plugins are now free to use in all licenses, you can also enable their full functionality on the license creation page.

This is how it works:

1. Choose the plugins you want to include in your license key:


2. Click on “Generate License Key” and set the app identifier & version code. You can see that the AdMob plugin was enabled in this license key:


3. Copy the generated licenseKey to your GameWindow or App component.


4. You can now fully use the plugins!

New Firebase Qt Plugin

With the new Firebase plugin, you can:

  • Use Firebase Authentication for user authentication via email. This includes account creation, password recovery and of course login and logout functionality. This does not require your own backend.
  • Use the Firebase Realtime Database to store and sync data with the Firebase NoSQL cloud database. Data is synced across all clients in realtime, and remains available when your app goes offline.

The Firebase plugin comes with various examples and extensive documentation on how to use it. You can find it here.

Firebase Authentication

Most apps need to know the identity of a user. Knowing a user’s identity allows an app to securely save user data in the cloud and provide the same personalized experience across all of the user’s devices.

Firebase Authentication provides backend services to authenticate users in your app. The plugin currently supports authentication using e-mail and passwords. Additionally, the Firebase plugin comes with a “forgot password” feature, which you can easily use in your application without tedious setup.

You can design the login screen completely customized for your app. If you don’t want to do that, we’ve got you covered as well: You can easily create a login page template using our wizard. Just click File -> New File or Project -> V-Play Apps -> Page and in the next step, select Login Page as Page Type.

Firebase Realtime Database

Use the Firebase Realtime Database to store and sync data with the Firebase NoSQL cloud database. Data is synced across all clients in realtime, and remains available when your app goes offline.

The Firebase Realtime Database is a cloud-hosted database. Data is stored as JSON and internally synchronized in realtime to every connected client.

When you build cross-platform apps with the Realtime Database, all of your clients share one Realtime Database instance. The Firebase backend automatically receives updates with the newest data as soon as the database is changed by one of the clients. Additionally, changes to the database are propagated to other clients and can be read by the clients in real time.


As an alternative to Firebase, V-Play also comes with its own easy to use WebStorage component, which connects to the V-Play backend. It is a simple key-value store which syncs across different devices and platforms via the V-Play Game Network Backend as a Service (BaaS).

More Fixes & Improvements

Besides the highlights mentioned above, there are many other fixes and improvements for the SDK. 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:

  • 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.11.0 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. Now you can explore all of the new features included in V-Play 2.11.0!

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

More Posts like This


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

How to Make a Qt app

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

Release 2-10-1

The post Release 2.11.0: All Monetization Plugins Now Free, Plugin Trial & Firebase Qt Plugin appeared first on V-Play Engine.