Release 2.8.2: Easier Plugin Integration & Debug Menu Improvements

V-Play 2.8.2 is now available to all V-Play users for free. This update offers a range of improvements to the SDK to make plugin integration and testing simpler for developers. It also features a number of minor fixes for V-Play Apps components. You can update now to check out the improvements for yourself.

Update Now!

If you’re not an existing V-Play user, you can download the SDK for free.

V-Play Plugins

The release of V-Play 2.8.2 means a drastic improvement in the way 3rd party plugins are added to mobile apps and games.

Using V-Play Plugins before 2.8.2 required you to install the plugin libraries from an additional repository in the Maintenance Tool. Beginning with V-Play 2.8.2, plugins are part of V-Play Engine libraries. This reduces the necessary amount of code and time it takes to integrate plugins.


With V-Play Plugins, you can monetize your app or game. Admob, Chartboost and Soomla allow you to advertise and enable in-app purchases.

Google Analytics is an industry-standard plugin for measuring user events. Flurry, Infinario and HockeyApp also allow you to gather data on user interactions.

The Facebook plugin and the V-Play Game Network allow you to increase retention by engaging users. All of the V-Play Plugins are available with the V-Play Indie License.

If you’re already using V-Play Plugins, you can check out our migration guide for using the new integration method. This migration guide is only for pre-existing V-Play Plugins users.

Debug Menu Improvements

V-Play recently added a Debug Menu that enables quick UI and UX testing. V-Play 2.8.2 has improved this feature for both apps and games. The Debug Menu now reduces the application window for resolutions that don’t fit on screen.

In addition, the UI is now scaled to simulate the selected device.


The Debug Menu allows for better testing of games and apps during development builds: you can easily switch between different platforms and screen resolutions while testing on desktop machines.

You can choose between Desktop, iOS and Android themes and see the differences instantaneously, even when the app is running, without needing to re-run the app or have a real device for testing.


V-Play 2.8.2 includes two fixes:

  • A Sample Launcher issue with Theme initialization when running app demos.
  • A bug on Android 4 devices that caused the home button to stop working.

How to Update

Test out these new features by following these steps
Step 1

Open the V-Play SDK Maintenance Tool in your V-Play SDK directory. Choose “Update components” and finish the update process to get V-Play 2.8.2 as described in the V-Play Update Guide

If you haven’t installed V-Play yet, you can do so now with the latest installer from here.

Step 2

The V-Play Sample Launcher allows you to quickly test and run all the open-source examples and demo apps & games that come with the V-Play SDK, from a single desktop application.

After installing V-Play, you can start the V-Play Sample Launcher from the application shortcut in your V-Play SDK directory.

V-Play Sample Launcher

Now you can explore all of the new features included in V-Play 2.8.2!

More Posts like This

How to Make a Game like Super Mario Maker with Our New Platformer Level Editor

Platformer Level Editor

16 Great Sites Featuring Free Game Graphics for Developers

game graphics

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

tutorials capture

21 Tips That Will Improve Your User Acquisition Strategy

User Acquisition


The post Release 2.8.2: Easier Plugin Integration & Debug Menu Improvements appeared first on V-Play Engine.

Qt World Summit 2016 | Call for Speakers – We need your best work!


It is the time of the year again when the #1 Qt event of the year, Qt World Summit, is a approaching and Call for Papers is now open. Qt World Summit 2016 is held October 18-20, 2016 in San Francisco, CA.

At the Qt World Summit, we celebrate the synergy of Qt, the ecosystem, and technology. We are passionate about enabling innovation, interactivity, enhanced user experiences, IoT, application development, device creation and visualization (to name a few!), and keen on the points of connection and collaboration among the disciplines. For more than 12 years, our conference has served as a hub, bringing together technology innovators, industry experts, creative startups, and device creators who continue to inspire, educate, and show innovative approaches to various communities within application development and device creation techniques–as well as the latest trends around the Qt roadmap, API offerings, tips’n’tricks and hands-on tutorial sessions!

Qt World Summit 2016 will continue to build on this legacy while striving to create stronger ecosystem among our existing, converging and emerging communities. We are determined to render the exponential potential that arise when software systems, ideas, and techniques intertwine.

To do this, we need your best work! Qt World Summit 2016 offers a variety of opportunities for you to present, network, and be an integral part of the conference. Now, we are seeking submissions along the main themes of the conference:

  • Creating Connected Devices and Internet of Things
  • Things getting smaller
  • Next generation graphics approaches
  • The future of user interfaces and 3D
  • Software as a differentiator – Industries being revolutionized by software: Automotive, Medical/Health, Consumer Electronics,  Industrial Automation, Aerospace/Defense and more
  • Software solution for multi-platform development – desktop, mobile and embedded

For these themes, we are looking for inspiring strategy and industry talks (Technology Strategy) as well as more hands-on technical talks (Qt for Application Development and Device Creation).

For the full details of the themes, submission categories and instructions, please view the Qt World Summit 2016 Call for Speakers document and Submit your talks here.

From mission-critical work to newly developed technologies, lecture-based workshops to consumer electronics project strategies, real-time operating systems to experiential installations, mobile applications to innovative animations and visual effects, submissions will be reviewed and evaluated by our experts from a plethora of specializations.

Of course, there are deadlines! Qt World Summit Call for Papers deadline is May 20th, and we don’t want to miss your submission. Feel free to contact Qt World Summit 2016 program chairs regarding the submission process. We’ll be happy to hear your questions, comments, or ideas.

Contact if you have any questions.

That being said, on behalf of the Qt World Summit 2016 program committee, I invite you to contribute and to join us this fall in beautiful San Francisco, California for another educational, stimulating, and memorable gathering of the worldwide Qt ecosystem. With you, we hope to shape and imagine the exponential potential of our future.

I look forward to seeing you (talk!) at #QtWS16!

And again, submit your talk here!


The post Qt World Summit 2016 | Call for Speakers – We need your best work! appeared first on Qt Blog.

Fast-Booting Qt Devices, Part 2: Optimizing Qt Application

Welcome back to the fast-boot blog post series! Last week we covered the fast-boot demo that showed you a video of an i.MX6 board booting under 2 seconds. In this blog post we will cover how the Qt QML cluster application was optimized.

The original demo shown in Qt World Summit 2015 was designed in PC environment and the startup time was not addressed with the initial design. Design already incorporated usage of Loaders so that some parts of the UI were asynchronously loaded but the startup sequence was not thought at all. So, to begin the optimization for the startup we first needed to think of the use case: What is it that we want the user to see first? We selected that the first thing the user must see is the frame of the cluster after which we load and animate the rest of the objects to the screen.

In the cluster image below the red overlay marks the parts we decided that user must see when the application starts:


When looking at the application code we noticed that our dashboard was actually combination of multiple different mask images and some of these were fullscreen. So we combined all the visible parts into one single full screen image that gets loaded on top of the UI:



To make the startup of the application as fast as possible we adjusted the internal design of the application as well. We separated the dashboard frame into it’s own QML file that gets loaded as a very first item. After cluster frame is loaded and drawn we enable the loader underneath to load rest of the UI.


We also used the QML profiler in Qt Creator to find out what was taking time. Initially the demo used the original Qt Quick Controls that were designed for desktop. This caused the creation of these gauges take some extra time (note that, Qt Quick Controls are being redesigned for embedded use cases for Qt 5.7!) To solve this part for now, we replaced the gauges with images and created a fragment shader to color the parts of gauges that needs animation.

As a final touch we added the flip animation to gauges and fade in to the car to make startup feel more natural:

After these optimizations we got the Qt application to show the first frame under 300 milliseconds on the target device (from the time operating system kernel is loaded).

Optimizing Your Application: ‘Do’s and ‘Do not’s!

Finally, based on our experience, here is a summary of tips’n’tricks for optimizing your Qt Quick applications. In case you feel like you could use additional help, feel free to contact us or any of our Qt Partners and we’re happy to help you with your application!


  • Design your application to start fast from the beginning. Think what is it that you want the user to see first.
  • Make startup animations to allow parallel loading.
  • Use chain loading. Run only as many loaders as you have cores in your CPU (e.g two cores: two loaders running at the same time).
  • First loader should not be asynchronous. Trigger the rest of the loaders.
  • Create QML plugins that are loaded when required.
  • Connect to back-end services only when required.
  • Let the QML plugins start up non-critical services and close those down when not required anymore.
  • Optimize your png / jpg images.
  • Optimize your 3d models by reducing the amount of vertices and removing parts that are not visible.
  • Optimise the 3D model loading by using glTF.
  • Use Qt Quick Controls 2.0. These are designed for embedded use and the creation times are a lot better than in Quick Controls 1.0 for embedded use cases.
  • Limit the usage of clip & opacity.
  • Measure GPU limitations and take those into account when designing the UI.
  • Use Qt Quick Compiler to pre-compile the QML files.
  • Investigate if static linking is possible for your architecture.
  • Strive for declarative bindings instead of imperative signal handlers.
  • Keep property bindings simple. In general, keep QML code simple, fun and readable. Good performance follows.
  • When targeting multiple platforms and form factors, use file selectors instead of loaders and dynamic component instantiation. Don’t be shy to “duplicate” simple QML code and use file selectors to load tailored versions.

Do not:

  • Go overboard with QML. Even if you use QML, you don’t need to do absolutely everything in QML.
  • Initialize everything in your main.cpp.
  • Create big singletons that contain all the require interfaces.
  • Create complex delegates for Listviews.
  • Use Qt Quick Controls 1.0 for embedded.
  • Clip should be avoided altogether if possible. (98% of the use cases this should be possible).
  • Fall into the common trap of overusing Loaders. Loader is great for lazy-loading larger things like application pages, but introduces too much overhead for loading simple things. It’s not black magic that speeds up anything and everything. It’s an extra item with an extra QML context.
  • Overdo re-use. Maximum code re-use often leads to more bindings, more complexity, and less performance.

In the next part of the series, we will look more closely into the operating system side of the startup optimization. Stay tuned!

The post Fast-Booting Qt Devices, Part 2: Optimizing Qt Application appeared first on Qt Blog.

Qt Quick Designer and Qt Quick Controls 2

Qt 5.6 introduced the Qt Quick Controls 2 and they are already integrated in the upcoming release of Qt Creator 4.0.

We took this as a reason to create a video that shows how the new controls can be used to build a UI easily using Qt Creator and the integrated Qt Quick Designer.

The video shows how we create the UI of a simple home automation application for a touch device. Finally we run the software on a hardware with the boot2qt stack installed.

The UI uses the material style that comes with the Qt Quick Controls 2. We also show a couple of new features that help to maintain the split between .qml and .ui.qml files.

All these features are both in the free Open Source version and the commercial version of Qt Creator 4.0.

The post Qt Quick Designer and Qt Quick Controls 2 appeared first on Qt Blog.

Creating Certified Systems with Qt

When there is a need to use Qt as part of a system requiring functional safety certification, it is typically best to analyze if the safety critical functionality can be separated. This approach allows the safety critical functionality to be implemented without the need to certify the complete software stack of the system.

In my earlier blog post I explained the fundamentals of functional safety as well as introduced some of the industry specific standards for functional safety. If you missed that, I recommend to read it first. In this second blog I will explain what certification of Qt would mean in practice and present two architectures for creating a functional safety certification for a Qt based system.

What about Certification of Qt for Functional Safety?

Qt has been used in various systems requiring certification, and a bit over a year ago we decided to investigate if and how Qt itself could be certified for functional safety. The analysis was mainly conducted against IEC 61508, which sets the baseline for industry specific standards on functional safety, and automotive ISO 26262. Two separate pre-studies were conducted by The Qt Company together with VTT Expert Services, who is a certification authority for various standards, including IEC 61508. Based on these pre-studies and analysis of IEC 61508 and ISO 26262 it was concluded that it is in essence possible to certify core parts of the Qt framework for functional safety. However, balancing the effort, cost and needed functional changes related to the certification effort, we believe that aiming to get safety certification of the Qt framework is not sensible or meaningful in technical nor business wise. Our aim is to make it easier than before to use Qt in certified systems, and to work with our customers to achieve the certificates they need.

It is possible to use Qt as an integral part of a system certified for functional safety, without changes to the Qt framework. When the safety critical functionality of the certified system is adequately separated, it is not necessary to certify other parts of the system software. Thus it is possible to create a certified system with Qt without certifying the Qt libraries. In the next chapters, I will cover how to achieve the needed functional safety with a system containing Qt and present two alternative system architectures for this purpose.

Using Qt in Safety Critical Systems

If a product, for example an embedded system, contains both certified and non-certified components, it is crucial to adequately separate these. If the safety critical software can’t be reliably separated from the other software, the whole system should be certified for functional safety. In practice it is typically much better choose a system architecture that separates safety critical functionality from the other functionality. Such separation is beneficial especially in cases when the system contains a complex UI and application functionality.

Leveraging a Real Time Operating System

One approach is to leverage a certified real-time operating system for separation of the certified and non-certified software. This is well feasible as Qt supports several real time operating systems that have a proven way to separate the safety critical and other functionality. This approach is especially good in applications where the unique capabilities of the used real time operating system are a good fit for the application’s needs, i.e. the needed functionality of the application is feasible with the chosen real-time operating system.


Figure 1. Using a certified RTOS to separate safety critical functionality.

With this architecture the real-time operating system provides the capability to separate safety critical and other processes. The overall system architecture leverages just one operating system kernel managing both safety critical and other processes. Typically, the real-time operating system can also provide a guarantee that certain functions get run when needed, a feature often beneficial in creation of systems that need certification. As the operating system fully separates the functionality which is not safety critical, certification is needed only for the safety critical parts. Many real time operating systems offer a certified or pre-certified kernel and toolchain, thus using these saves time and effort in system level certification.

Leveraging a Hypervisor

Another system architecture for separation of the non-certified components from the certified, safety critical, parts of the embedded system is to use a hypervisor. In this approach a hypervisor is leveraged to run two or more different operating systems. For example, one for safety critical functionality and one or more for the other parts of the system. Typically, a so called Type 1 or bare-metal hypervisor is a good approach for embedded systems that need to run a separate operating system for certified and non-certified functionality.


Figure 2. Using a certified hypervisor to separate safety critical functionality.

Certified functionality can run on a simple real time operating system that has sufficient capabilities to provide the needed safety functions. Non-certified functionality can run for example on embedded Linux, which offers the possibility to utilize all the capabilities of Qt. As the real time operating system does not need to run Qt or any other complex components, it can be simpler and more lightweight than in the architecture that leverages a real time operating system for separation (and to run Qt).

Having the certified parts as streamlined as possible benefits a lot, as it is easier to implement the requirements of safety critical software and there is no need to certify functionality that is not safety critical. Additionally, using a regular embedded Linux for the functionality that is not safety critical typically makes it easier to implement complex functionality, which can result in significant cost savings for the overall system.

Achieving Certified Graphics

In a Qt based system it is common that the UI functionality is provided by Qt. If there is no safety critical UI functionality, the approach for graphics is very straightforward: Qt can handle everything related to the display without impact to any of the safety critical functionality.

However, if the safety critical functionality includes some UI related items, for example a warning light or a message, it needs to be handled by the safety critical part of the system. This means that the architecture has to allow sharing of the screen between safety critical and regular UI components in a way that guarantees operation of the safety critical functionality.

One approach to achieve such co-existence in the display is to leverage hardware layers of the system to guarantee that the safety critical UI component is drawn to the topmost layer. With this approach the safety critical UI is visible despite of a possible failure condition in the other functionality, as any possible failure in other functionality does not overwrite it. Another possibility would be to handle all of the UI composition in the safety critical part of the system. Having composition completely done within the certified functionality slightly complicates the overall graphics architecture, but is a possibility.

If there is dynamic content mandating hardware acceleration required also for the safety critical functionality, usage of an OpenGL SC certified GPU software needs to be considered. Such approach makes the system design more complex, so it is always easier if the UI requirements of the safety critical functionality are limited. Selection of the architecture for safety critical user interface components depends on the capabilities of the used hardware and operating system, as well as the application use case.

If you are interested in discussing more on the creation of functional safety certified systems with Qt, please contact us.

The post Creating Certified Systems with Qt appeared first on Qt Blog.

Qt 5.7 Beta Released

Qt 5.7 Beta is now released and available for your feedback. There is a lot to review – new modules, leveraging C++11 features, and the new unified product structure, which is now the same for both commercial and open source versions.

Leveraging C++11

The core of Qt comes from its C++ foundation and the powerful native performance it offers you. We of course always want to ensure Qt is on top of the latest C++ developments, so that the framework continues to grow with your needs. Qt has supported the use of C++11 in application code for a long time. We also wanted to keep supporting C++98 compilers up to Qt 5.6, which meant that we needed to wait before fully leveraging C++11 features in the Qt framework libraries themselves.

Starting with Qt 5.7 all compilers are C++11 compatible, which allows us to start using new C++ functionality such as auto, lambda and many more in Qt itself. These features will also start to appear in the Qt API, where it makes sense to do so. For those who can’t move yet the long term supported Qt 5.6 provides full C++98 compatibility.

New Functionality

Our focus with Qt 5.6 is on Long-Term Support quality, so lots of new features and functionality will now be coming with Qt 5.7. The Qt Company and our valued contributors managed to do this by developing Qt 5.7 in parallel with completion Qt 5.6 LTS. Qt 5.7 provides a fully supported version of Qt Quick Controls 2 and Qt 3D. It also provides a technology preview of Qt Wayland Compositor, Qt SCXML, Qt SerialBus and Qt Gamepad modules. The Qt 5.7 Beta installers also pack in Qt Creator 4.0 RC.

For full list of all the goodies in Qt 5.7, please check the New Features of Qt 5.7 on the wiki.

Open-Source Licensing Change

As announced in January, Qt is adjusting the open-source licensing starting with the Qt 5.7 and Creator 4.0 releases. Most of the Qt framework will be licensed under your choice of LGPLv3, GPLv2 or our commercial license. In addition, many of the previously commercial only add-on libraries will be made available either under GPLv3 or LGPLv3. Qt Creator, as well as other tools and applications, will be licensed under GPLv3 (with exceptions to enable development of non-GPL applications) and our commercial license.

For more information about the license change, please check the License change FAQ and the blog post announcing the change.

Unified Product Structure

The open-source license change with Qt 5.7 allows us to unify the structure of Qt for Application Development product for both commercial and open-source users in that you will get the same features regardless of the license. One exception though is Qt Quick Compiler, which will only be available under commercial licensing in Qt 5.7. However, we aim to introduce a new built-in Qt Quick Compiler with Qt 5.8, which will be available for both commercial and open-source users. Our product offering for embedded users – Qt for Device Creation – continues to have exclusive functionality available only for commercial licensees.

Get Qt 5.7 Beta

The Qt Company has prepared convenient binary installers for the Qt 5.7 Beta, in the hopes that you will download, test and provide feedback so that we can deliver an awesome final product. To try out the new features you can download it from your Qt Account or from For any issues you may find with the Beta, please submit a detailed bug report to (after checking for duplicates). You are also welcome to join the discussions in the Qt Project mailing lists, development forums and to contribute to Qt.

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

Fast-Booting Qt Devices, Part 1: Automotive Instrument Cluster

When creating embedded devices, one crucial part of the user experience is also the boot-up time of the system. In many industries, such as Automotive, there are also hard requirements for the boot-up time.

We get a lot of questions like “How quickly can devices built with Qt start?”,  “Can you boot up a system to a Qt application under 2 seconds?”, or, “What’s the minimum time required for a system to start a Qt application?”

Unfortunately, there is no single answer for the questions. Thus, we decided to create three blog posts to open up a bit how to optimize your Qt-powered embedded systems. In this first part, we will look into automotive instrument clusters as a specific use case and show our instrument cluster showcase fast-booting with some benchmark statistics. The second part will focus more on the practical ‘how’ part: optimizing the Qt, and especially Qt Quick, application code. Finally the third part will discuss more about the hardware side of boot-up optimization.

The Qt Automotive Instrument Cluster Showcase

In the automotive industry, there is a clear need for fast boot-up times. For example, in the digital instrument clusters, it is crucial to start as quickly as possible: When the car is started, the instrument cluster needs to be up, running and reacting almost immediately. Besides fluent user experience, this is also something controlled by official safety requirements. At the same time, as the clusters get more digitalized and graphically much more verbose with e.g. 3D contents, this is something that requires extra attention from the software design and the underlying platform/framework. To demonstrate that fast-booting instrument clusters is possible by using Qt, we took our Embedded world 2016 instrument cluster demo setup and optimized it.

Take a look at the video to see the results:

The original boot-up time of the demo setup was a bloated 23 seconds. After the optimization, we were able to get the first parts of the screen visible already in around 1.5 seconds, depending on what services are required.

Analyzing the time consumption

From the video we have analyzed and approximated where the time goes:


The complete boot time from power off to first frame visible is 1 560 ms. As you see, majority of the time is actually spent on other items than the Qt application contents. For those parts, we still think that time could be even shorter by selecting a different hardware that can be powered up faster. Also, the board could have a faster memory and memory bus. The u-boot could still be stripped down more or replaced with a custom boot loader. But a lot of improvement was done in general, especially for the Qt Quick application optimization.

Prioritizing views

First and the most important thing before starting the optimization is to think what do you want the user to see first. Then start your application UI with that thing only, and lazy-load the rest dynamically. We selected that user must see the frame of the instrument cluster, and after the frame is drawn, the rest of the components are loaded dynamically. First, we load the gauges and only after that, the 3D car model.

“Cheating” by pre-loading

One way to improve the user experience is to “cheat” a bit on when to actually start the loading, if the startup has to be even faster than is possible with an optimized boot. For the instrument cluster use case, you could actually do the startup when the car door is unlocked or opened. In such approach the system is already running by the time the driver enters the car, and system only needs to engage the back light of the instrument cluster when driver switches power on.

How was the Qt part optimized in practice?

For the practical how-to optimization of the Qt Quick application, I’m going to need you to wait for the next part of the blog post series. In part two, we will talk about the practical tips and tricks around optimizing the Qt application.

Stay tuned!

The post Fast-Booting Qt Devices, Part 1: Automotive Instrument Cluster appeared first on Qt Blog.

Qt Creator 4.0 RC1 released

We are happy to announce the release of Qt Creator 4.0 RC1 !

I’d like to refer you to the beta blog post for an overview of the new features coming in the 4.0 release. Since then we have been fixing bugs busily, and we believe that what we have now is very near to what we can release as the final 4.0 release soon.

Our icons and the new “Flat” theme also received a lot of polish, and “Flat” is now the default theme for everyone who hasn’t ever changed the theme in Qt Creator. The old theme is also still available as “Classic” in Tools > Options > Environment > Interface.

So this is a good time to head over to our download page or the Qt Account Portal, get and install the RC and post us your feedback, preferably through our bug tracker. You also find us on IRC on #qt-creator on, and on the Qt Creator mailing list.

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

QRegion will be iterable in Qt 5.8

A novel solution to an old problem

The QRegion class specifies a clip region for a painter. You can also query a QPaintEvent for the region() to limit the paint operations necessary in partial repaints.

A region can be anything from a simple rectangle to a bitmap mask, but virtually all code that inspects a QRegion does so by decomposing the region into non-overlapping rectangles and looping over the rectangle list.

Traditionally, the only way to do this has been by calling rects(), which returns a QVector<QRect>.

But rects() has a problem: In the very common case that the region contains just one rectangle, the QRegion is internally represented by a QRect and not a QVector, and the mere act of calling rects() makes QRegion create one.

Clearly, the memory allocation involved in creating a QVector just to return a single rectangle is not helpful. Indeed, Qt developers usually work around this problem by inspecting QRegion::rectCount() before calling rects() and resolve to calling QRegion::boundingRect() instead for regions with just rectangle.

Lack of efficient computational basis

That is really bad API, but it’s hard to spot.

Alexander Stepanov, the inventor of the STL, tells us that a class should provide an efficient computational basis (Elements of Programming, p.6), and allocating memory in the most common situation squarely fails that test.

We also all know that APIs should be easy to use correctly and hard to use incorrectly. But in this case, the straight-forward way of using the API:

void inspect(const QRegion &region) {
    for (const QRect &rect : region.rects())

is different from the correct way of using the API:

void inspect(const QRegion &region) {
    if (region.rectCount() == 1) {
    } else {
        const auto rects = region.rects(); // make const to avoid a detach in the implicit begin() call below:
        for (const QRect &rect : rects)

Not only is the first version easier to read and maintain, it also expands to a lot less executable code.

But we can do much better…

QRegion as a container of QRect

Realising this problem, I resolved to fix it by exposing to users the fact that QRegion is a container of QRects.

I did this by providing iterators and begin()/end() on QRegion. The functionality has been merged for Qt 5.8.

Unlike rects(), the new functions can be noexcept, saving even more executable code in projects that, unlike Qt itself, don’t switch off exceptions.

The iterator type is just const QRect*, so as to abstract away the difference between iterating over a QVector<QRect> and over a single QRect. Quoting qregion.cpp:

    const QRect *begin() const Q_DECL_NOTHROW
    { return numRects == 1 ? &extents :; } // avoid vectorize()

    const QRect *end() const Q_DECL_NOTHROW
    { return begin() + numRects; }

No mutable iterators are provided

Because QRegion maintains a running bounding-rect, a mutable iterator would have to call into QRegion for every change, which doesn’t make sense. Consequently, no mutable iterators are provided for QRegion.

As a nice side-effect, that means that begin() and end() are const and thus do not cause the hidden detaching problem that plagues other Qt container classes.

In particular, QRegions can now be used as an argument to C++ range-for loops without Qt 5.7’s qAsConst() protection:

void inspect(const QRegion &region)
    noexcept(noexcept(inspect(std::declval<QRect&>()))) // noexcept whenever inspect(QRect) is
    for (const QRect &rect : region)


Apart from providing a non-allocating, non-throwing way to inspect a region, there are other positive effects. Because no QVector is returned that needs to be destroyed by the caller, even in projects (such as QtGui) that are compiled with exceptions disabled, porting even a few loops to the new construct saves more than 1KiB in text size on optimized GCC 5.3 Linux AMD64 builds, not to mention countless memory allocations at runtime.

The post QRegion will be iterable in Qt 5.8 appeared first on KDAB.

Qt on Android: How to convert Qt images to Android Images and vice-versa

Sometimes we need to exchange images from Android world to Qt world and vice-versa, therefore in this article we’re going to see how to convert a QImage to an Android Bitmap and how to convert an Android bitmap and an Android Drawable into a QImage.

To get access to Android Bitmap data & info we’re going to use NDK’s support, so we need to make sure jnigraphics library is in libraries dependency in our .pro file:

LIBS += -ljnigraphics

Now let’s see what the convert functions looks like:

#include <QAndroidJniEnvironment>
#include <QAndroidJniObject>
#include <android/bitmap.h>

QImage toImage(const QAndroidJniObject &bitmap)
    QAndroidJniEnvironment env;
    AndroidBitmapInfo info;
    if (AndroidBitmap_getInfo(env, bitmap.object(), &info) != ANDROID_BITMAP_RESULT_SUCCESS)
        return QImage();

    QImage::Format format;
    switch (info.format) {
        format = QImage::Format_RGBA8888;
        format = QImage::Format_RGB16;
        format = QImage::Format_ARGB4444_Premultiplied;
        format = QImage::Format_Alpha8;
        return QImage();

    void *pixels;
    if (AndroidBitmap_lockPixels(env, bitmap.object(), &pixels) != ANDROID_BITMAP_RESULT_SUCCESS)
        return QImage();

    QImage image(info.width, info.height, format);

    if (info.stride == uint32_t(image.bytesPerLine())) {
        memcpy((void*)image.constBits(), pixels, info.stride * info.height);
    } else {
        uchar *bmpPtr = static_cast<uchar *>(pixels);
        const unsigned width = std::min(info.width, (uint)image.width());
        const unsigned height = std::min(info.height, (uint)image.height());
        for (unsigned y = 0; y < height; y++, bmpPtr += info.stride)
            memcpy((void*)image.constScanLine(y), bmpPtr, width);

    if (AndroidBitmap_unlockPixels(env, bitmap.object()) != ANDROID_BITMAP_RESULT_SUCCESS)
        return QImage();

    return image;

This function doesn’t have any JNI magic, and it’s quite simple. We try to find the best QImage::Format (To be honest I’m not very sure about ANDROID_BITMAP_FORMAT_RGBA_4444), then we copy the image data from Android bitmap to our QImage.

Being able to convert any Android Drawable to a QImage is quite useful, therefore, let’s check how to “convert” (actually draw) an Android drawable into a QImage.

QAndroidJniObject createBitmap(int width, int height)
    QAndroidJniObject config = QAndroidJniObject::getStaticObjectField("android/graphics/Bitmap$Config",

    return QAndroidJniObject::callStaticObjectMethod("android/graphics/Bitmap",
                                                     width, height, config.object());

QImage toImage(const QAndroidJniObject &drawable, const QRect &bounds)
    QAndroidJniObject bitmap = createBitmap(bounds.width(), bounds.height());
    QAndroidJniObject canvas("android/graphics/Canvas", "(Landroid/graphics/Bitmap;)V", bitmap.object());
    drawable.callMethod<void>("setBounds", "(IIII)V", bounds.left(),, bounds.right(), bounds.bottom());
    drawable.callMethod<void>("draw", "(Landroid/graphics/Canvas;)V", canvas.object());
    return toImage(bitmap);

First function (createBitmap) is used to create an RGBA_32 bitmap, we’re going to use this function in the next snippet too. Second function (toImage) draws the drawable into a bitmap canvas, then it converts the bitmap using previous toImage function.

Finally, let’s see how to convert a QImage to an Android Bitmap

QAndroidJniObject toAndroidBitmap(const QImage &img)
    QImage image = img.format() == QImage::Format_RGBA8888 ? img : img.convertToFormat(QImage::Format_RGBA8888);
    QAndroidJniObject bitmap = createBitmap(img.width(), img.height());
    QAndroidJniEnvironment env;
    AndroidBitmapInfo info;
    if (AndroidBitmap_getInfo(env, bitmap.object(), &info) != ANDROID_BITMAP_RESULT_SUCCESS)
        return QAndroidJniObject();

    if (info.format!= ANDROID_BITMAP_FORMAT_RGBA_8888)
        return QAndroidJniObject();

    void *pixels;
    if (AndroidBitmap_lockPixels(env, bitmap.object(), &pixels) != ANDROID_BITMAP_RESULT_SUCCESS)
        return QAndroidJniObject();

    if (info.stride == uint32_t(image.bytesPerLine())) {
        memcpy(pixels, image.constBits(), info.stride * info.height);
    } else {
        uchar *bmpPtr = static_cast<uchar *>(pixels);
        const unsigned width = std::min(info.width, (uint)image.width());
        const unsigned height = std::min(info.height, (uint)image.height());
        for (unsigned y = 0; y < height; y++, bmpPtr += info.stride)
            memcpy(bmpPtr, image.constScanLine(y), width);

    if (AndroidBitmap_unlockPixels(env, bitmap.object()) != ANDROID_BITMAP_RESULT_SUCCESS)
        return QAndroidJniObject();

    return bitmap;

This function is quite simple, we’re using createBitmap from a previous snippet to create an Android Bitmap object, then we copy the QImage content to Android Bitmap.

The post Qt on Android: How to convert Qt images to Android Images and vice-versa appeared first on KDAB.

Grantlee v5.1.0 (Codename Außen hart und innen ganz weich) now available

The Grantlee community is pleased to announce the release of Grantlee version 5.1 (Mirror). Grantlee contains an implementation of the Django template system in Qt.

This release is binary and source compatible with the previous Qt5-based Grantlee release.

Following the pattern of naming Grantlee releases with German words and phrases I encounter, this release codename reflects the API being stable while the internals change a lot. Grantlee is “Allzeit bereit”, “einfach unerzetzlich” – it does everything “ganz ganz genau”:).

For the benefit of the uninitiated, Grantlee is a set of Qt based libraries including an advanced string template system in the style of the Django template system.

{# This is a simple template #}
{% for item in list %}
    {% if item.quantity == 0 %}
    We're out of {{ }}!
    {% endif %}
{% endfor %}

The showcase feature in this release is the introduction of ==, !=, <, >, <=, >= and in operators for the if tag. Django has had this feature for many years, but it was missing from Grantlee until now.

Also notable in this release is several changes from Daniel of Cutelyst. Daniel ported Grantlee from QRegExp to the more modern QRegularExpression, better error checking, and lots of prototyping of the if operators feature.

In order to accommodate CMake IDE generators (Visual Studio/Xcode) plugins built in debug mode now gain a ‘d‘ postfix in their name. Grantlee built in debug mode will first search for a plugin with a ‘d‘ postfix and fall back to a name without the postfix. This should make it possible to use a different generator to build Grantlee than is used to build 3rd-party plugins (eg, NMake and Visual Studio), and still be able to use the resulting binaries.

All of the work on making everything work well with all CMake generators was concurrent with making use of Travis and AppVeyor. All changes to Grantlee now have a large quality gate configuration matrix to pass. Of course, Qt handles all the platform abstractions needed here in the C++, but people build with many different configurations, CMake generators and platforms which need to continue to work.

All of the other changes since the last release are mostly clean-ups and minor modernizations of various kinds

  • Make it possible to build without QtScript and QtLinguistTools
  • clazy-discovered cleanups
  • Modernization
  • Bump the CMake requirement to version 3.1 and the Qt requirement to version 5.3

I’m giving an introductory talk later today about Grantlee.

Overview of Functional Safety

Qt is used in an extremely wide variety of use cases across over 70 industries, and sometimes there is a need to use Qt in a safety critical system. When a system, be it a medical device, railway control system, nuclear power plant or an automobile, can potentially cause harm to humans, the concept of functional safety helps in assessing the risk and taking the necessary measures to steer the risk to an acceptable level. In this blog, I will explain the key concepts for functional safety and list a few industry standards of functional safety. 

What is Functional Safety?

The objective of functional safety is freedom from unacceptable risk of physical injury or of damage to the health of people. In many systems, there is always risk and the aim is to bring it down to a tolerable level and to reduce the impact of failure. At its simplest a functional safety system detects a potentially dangerous condition and causes corrective or preventative action to be taken.

Functional safety relies on active systems, for example the detection of smoke by sensors and the initiation of fire extinguisher systems or a mechanism in a revolving door to detect a person that stands still to prevent hitting the person.

Functional safety does not only affect software. On the contrary most systems can be implemented with very limited or no software functionality at all. But when it comes to systems using Qt, we of course are mainly interested in how functional safety affects the system’s software architecture and implementation.

Industry Standards for Functional Safety

Different industries have defined their own standards for addressing functional safety, for example, EN 50128 for Railway applications, IEC 60601 for Medical devices and ISO 26262 for the Automotive sector. The ‘mother’ of all functional safety standards is IEC 61508, which defines the basic concepts of functional safety as well as the means to achieve the desired level of safety, so called Safety Integrity Level (SIL).


Figure 1. Examples of industry specific functional safety standards derived from IEC 61508.

In IEC 61508, there are four different SIL levels of functional safety, that have different requirements for achieving them. The required SIL level is determined based on likelihood for injury or death, for example. If a potential hazard is likely to happen or can cause a lot of damage, the required SIL level is higher. The highest levels are often more relevant for non-UI software, but this is of course a matter of system design.

Achieving Functional Safety

Functional safety can’t be determined without considering the system as a whole and the environment in which it interacts. It is always the final product that needs to be analyzed for impact to functional safety aspects. It is possible to certify any component of a system, which will help in certification of the final system. Still, making a system out of certified parts does not exempt it from a system certification.

Finally, it should be stated that even though only some systems are subject to functional safety certification, it is often beneficial to consider the advice given in the functional safety standards also for systems that are not intended to be certified. The standards can give good instructions and best practices for design, implementation and quality assurance of any systems that can potentially cause harm.

Achieving full functional safety certification is often challenging and costly as some of the requirements, especially for the higher levels, cause significant restrictions to software functionality. Therefore, it is essential to determine what is the safety critical functionality of the system that needs to be certified. If it is possible to separate the safety critical parts of the software from parts that are not safety critical, it is permitted to limit the certification activity only to the required subset of the system functionality.

Functional safety is a large topic, so I wanted to have just the introduction in this post. In the second part of the blog post I will continue on this topic and focus into using Qt in systems that need to be certified for functional safety. If you are interested in discussing more on creation of functional safety certified systems with Qt, please contact us, or stay tuned for the second part.


The post Overview of Functional Safety appeared first on Qt Blog.

Opening new horizons at QtDay Italy 2016

With the mixture of Qt-in-use sessions and technical talks, Qt Day Italy might rightfully remind you of Qt Days in other parts of the world. Qt users in China, Korea and Japan are accustomed to our QtDays where they get their annual dose of everything Qt. And now Italy is about to rock!

Though purely focused on the local developer ecosystem, this (for the most part) Italian-speaking event will definitely create a sense of belonging to the big family of Qtoholics… or Qtmaniacs… or basically, people who love Qt.

Qt Day Italy is the only Italian event entirely dedicated to Qt, organized by Develer, official Qt service partner.

The event kicks off with the QtLab, a full-immersion training day on April 29th delivered by Qt Certified Specialists from Develer. By the way, tickets are still available!

Frederik Gladhorn, The Qt Company Senior Manager will present the Qt Roadmap and talk about how the company pushes forward features and functions that benefit cross-platform development with each release.

“Qt 5.6.0 is the first long term support Qt release. In this talk you’ll learn about the implications of the long term release, directions where Qt is headed and which platforms are supported,” says Frederik. “There will be a humorous look at how easy it is to make a release for something as complex as Qt.”

Looking towards the future, Frederik will tell a story about ongoing developments inside The Qt Company and community.

“Qt has been improving its offering on the application side and in addition helps getting work on embedded devices done with ease. There will be a brief introduction to Qt for Device Creation as well as a quick licensing update to help understanding the legal side of things,” Frederik says.

Other topics at the Qt Day Italy include practical talks on Qt and related technologies, case studies of companies that have successfully implemented and deployed Qt solutions, and reports directly from the developers of Qt on the latest technical and commercial offerings. Check out the schedule at

The event will end with Petref Saraci’s ending keynote on UX development.

“This an inspirational talk that shows the Qt value proposition. The talk will cover topics on UX and Qt, and Qt innovations over the years. I will talk about how we see the role of Qt in the future of UX and what we are planning for it,” says Petref, Senior Sales Engineer at The Qt Company.

Developers at the event can take advantage of a real-time help desk. The Qt Company Sales and R&D teams will also be at the event to guide Qt Day Italy visitors in the complex world of licensing and to show some fancy Boot-to-Qt features (

To learn more about the event, visit

The event also has its own Twitter account – follow @QtDay on Twitter (event hashtag: #qtday16)

The post Opening new horizons at QtDay Italy 2016 appeared first on Qt Blog.

QtCon call for papers

QtCon wants you to submit a talk/presentation on your favourite Qt related topic now.

The talk can be very in depth, like what we usually have at Qt Contributors’ Summit. Or more generic, something that would appeal to open source developers using Qt.

As the call on the QtCon page says, QtCon is a unique event.


KDE Akademy, Qt Contributors’ Summit, FSFE Summit, KDAB and VideoLAN Dev Days have come together to create QtCon 2016, Sept 1 – 4, 2016, to be held in Berlin, Germany.

The conference runs from Sept 2 – 4. On Sept 1 there will be a day of Training from KDAB.  There will be talks, workshops, Birds of a Feather sessions (BoFs) and meetings, contributed to by everyone, as well as the traditional social events. KDE Akademy will then continue with BoFs from Monday 5th to Thursday 8th elsewhere in Berlin.

The conference will be at the bcc, in Berlin, which has the flexibility to run a diverse program of events so participants can attend presentations and meetings with a great variety of focus and interest. If you are a Qt user, you’ll get the top quality talks you’d expect from a Qt conference, as well as presentations and meetings across each of the participating communities. If you normally attend the VideoLAN annual event, you will have access to everything you usually expect from that, as well as the opportunity to learn what’s new from Qt contributors, KDE and FSFE, and so on.

Attendees who are not members of any of these communities are also welcome to join this unique, one-off event and take their pick from the unusually wide range of material.

Maybe you have something else you’d like to propose along these lines, not forgetting talks that non-developers will find interesting. Find out more and submit your papers here

The post QtCon call for papers appeared first on Qt Blog.

Making the Qt brand remarkable

In the process of demerger from Digia to become our own entity, The Qt Company is taking advantage of the momentum to embrace a brand renewal as it is increasingly important for Qt to strengthen its brand by capturing the significance of what we’re all about.

We’re aiming for a contemporary visual identity that expresses our solid position as the leading independent technology for cross-platform development. Qt is about powerful blocks of code that run anywhere on any device, on any operating system at any time. We built a visual system that reflects the same principles – a system that is based on one simple block that can conveniently be expanded into various layouts in a wide range of formats. The Qt logo has now evolved into solid sharp lines, revealing an intense energetic green. We welcome you to visit to see how we have already started to implement the new look and feel. For those of you needing usage guidelines please visit or take look at the video about the brand change.

The post Making the Qt brand remarkable appeared first on Qt Blog.

Demerger from Digia — Qt business to become a separate listed company

The Qt Company is in the process of a demerger from Digia to become its own business entity and to be listed on NASDAQ OMX Helsinki. The planned registration date is May 1st 2016. The purpose of the arrangement would be to enable both Qt with its international reach and Digia with its domestic focus to maximize their respective business opportunities in line with their strategy. This will also optimize corporate structure, management and financing for each entity. Since 2008, Juha Varelius (MSc. Econ.) has been President & CEO of Digia Plc and has now been chosen by the Board to be the CEO & President of the newly listed Qt Group Plc. The Qt Company will continue to run business as usual and customers will not be affected. More information about the demerger:

The post Demerger from Digia — Qt business to become a separate listed company appeared first on Qt Blog.

Exhibition & Conference: froglogic at QtDay 2016 in Florence

froglogic will be present again at the QtDay 2016 in Florence, this time from April 29th – 30th 2016.


April 29th – Training session with a froglogic representative at QtLab
April 30th – At our booth (right in front of the conference facilities) we are showing live demos, testing BDD and embedded HMIs using Squish GUI Tester!

If you would like to schedule a meeting at QtDay 2016 with a representative of froglogic, please contact us.

More information about QTDay 2016 in Italy.

Last years talk about Qt GUI Testing with Squish

QTDay GUI Testing with Squish

Related topics

Physically Based Rendering (PBR) in 10 minutes

If you happened to be at the NVIDIA GTC conference last week, you may have seen a Qt demo we developed showing a Dodge Viper in the Toradex booth. If that Viper looked especially cool, that’s partially because it was displayed using Physically Based Rendering (PBR). Alright… what exactly is PBR, and can I use it in my projects?

In a sentence, PBR replaces common shortcuts for rendering surfaces with methodologies rooted in the physical world. Sound intriguing? Download our whitepaper for a ten minute introduction to the subject and how it may affect you. What’s your experience with Qt and PBR?… Any other questions? 


The post Physically Based Rendering (PBR) in 10 minutes appeared first on KDAB.

How do you use Grantlee?

Grantlee has been out in the wild for quite some years now. Development stagnated for a while as I was concentrating on other things, but I’m updating it now to prepare for a new release.

I’m giving a talk about it in just over a week (the first since 2009), and I’m wondering how people are using it these days. The last time I really investigated this was 6 years ago.

I’m really interested in knowing about other users of Grantlee and other use-cases where it fits. Here are some of the places I’m already aware of Grantlee in use:

Many areas of KDE PIM use Grantlee for rendering content such as addressbook entries and rss feeds along with some gui editors for creating a new look. The qgitx tool also uses it for rendering commits in the view with a simple template.


It is also used in the Cutelyst web framework for generating html, templated emails and any other use-cases users of that framework have.

There is also rather advanced Grantlee integration available in KDevelop for new class generation, using the same principles I blogged about some years ago.

It is also used by the subsurface application for creating dive summaries and reports. Skrooge also uses it for report generation.

It is used in Oyranos buildsystem, seemingly to generate some of the code compiled into the application.

Also on the subject of generating things, it seems to be used in TexturePacker, a tool for game developers to create efficient assets for their games. Grantlee enables one of the core selling points of that software, enabling it to work with any game engine.

Others have contacted me about using Grantlee to generate documentation, or to generate unit tests to feed to another DSL. That’s not too far from how kitemmodels uses it to generate test cases for proxy model crashes.

Do you know of any other users or use-cases for Grantlee? Let us know in the comments!

Qt Virtual Keyboard support on Hawaii

Ever since Qt Virtual Keyboard was introduced a couple of years ago I desired to integrate it with Hawaii, especially considering the effort to make the whole workspace adapt to different devices started a while ago.

However Qt Virtual Keyboard was a value-add component for Qt Enterprise customers, until things changed recently.

As part of the recent licensing change announcement, Qt Virtual Keyboard is now available also with GPLv3 license for Open Source users in addition to commercial Qt licensees.

This move allowed me to finally integrate Qt Virtual Keyboard with Hawaii, which soon will also be available on SDDM.

Qt Virtual Keyboard will be included with Qt 5.7 but it's possible to build the sources from the git repository now, against Qt 5.6.

The virtual keyboard is an input method so activating it is as easy as setting an environment variable, as outlined in the deployment guide:

export QT_IM_MODULE=qtvirtualkeyboard

To make it easier and less error prone a setting for Hawaii has been added that you can enable from the keyboard settings.

On desktop systems the keyboard is resized so that it won't cover search and password text fields.

Obligatory screenshots below:

Release 2.8.1: Spine Animations with V-Play & Qt and New File Wizards

V-Play 2.8.1 comes with a number of improvements, including support for spine animations. A new file wizard makes it faster to develop your apps and games by giving you access to templates for some of V-Play’s most common components. The update also fixes some compatibility issues that arose with the release of Qt 5.6 and some known bugs in the game engine.

V-Play 2.8.1 is a free update for all V-Play users. If you’re not an existing V-Play user, you can download the SDK for free.

Update Now!

Spine Animations with V-Play

With the release of V-Play 2.8.1, you can convert spine animations to QML and use them in your games. Spine animations allow you to include characters in your V-Play games that move in a life-like fashion.


Spine animations are bone-based animations that you create using the Spine Framework. In a nutshell, when one part of your character moves, the other body parts respond in a natural way.

These spine animations can now be used with Qt and included in your V-Play game. This feature allows you to create dynamic in-game characters that seem more alive than classic sprite animations.

In order to include Spine animations in your V-Play game, take a look at How to Add Spine Animations with V-Play! It will explain everything you need to know to make Spine animations and how to support them with V-Play.

New Templates and File Wizard

V-Play 2.8.1 offers new templates for app and game development, which are accessible through our improved file wizard. This new wizard will cut down your development time by allowing you to create file templates based on V-Play’s most common components.


For V-Play Games, you can now load file templates for Items, Scenes, and Entities. There’s also the option to create Custom Buttons and Dialogs.


For V-Play Apps, you can now load file templates for Items and Pages. The new file wizard is only available with the latest version of V-Play.


The following improvements for game and app development are included in V-Play 2.8.1

  • V-Play debug log messages are hidden by default when running qmake on your project (you can still display the messages when setting CONFIG += v-play_debug in your project file).
  • The GameWindow::displayFpsEnabled property now shows the fps at the correct position again if set to true.
  • Fixes issues when using the DEPLOYMENTFOLDERS project variable with Qt 5.6 that caused some builds to fail.
  • Fixes a possible app freeze on iOS when backgrounding a game that uses TexturePackerSpriteSequenceVPlay.

You can see a full account of all the improvements in V-Play 2.8.1 in our change log.

How to Update

Test out these new features by following these steps:
Step 1

Open the V-Play SDK Maintenance Tool in your V-Play SDK directory. Choose “Update components” and finish the update process to get V-Play 2.8.1 as described in the V-Play Update Guide

If you haven’t installed V-Play yet, you can do so now with the latest installer from here.

Step 2

The V-Play Sample Launcher allows you to quickly test and run all the open-source examples and demo apps & games that come with the V-Play SDK, from a single desktop application.

After installing V-Play, you can start the V-Play Sample Launcher from the application shortcut in your V-Play SDK directory.

V-Play Sample Launcher

Now you can explore all of the new features included in V-Play 2.8.1!

The post Release 2.8.1: Spine Animations with V-Play & Qt and New File Wizards appeared first on V-Play Engine.

Windows Dressing

Microsoft Windows has a long history of embedded operating systems going back to 1996, branded as Windows Embedded Compact, Windows Embedded CE, Windows CE, Windows Compact, Windows Phone, Windows Runtime, and an assortment of others. One of these fine platforms might even form the basis of your embedded product. Trouble is, with the shiny new Windows 10 IoT now on the horizon, this Windows Embedded family isn’t getting the love it used to.

Building a user interface? Let’s just hope your app isn’t still on MFC. Wait… it is? Sorry about that!

 If you’re thinking about updating your Windows Embedded legacy app, you’ll need an updated UX framework: lightweight enough for real-time, powerful enough to support modern GPUs, kitted up with a huge assortment of cross-platform tools, and supported by a host of companies.

You can see where I’m going with this… you guessed it: Qt.

Assuming you want to facelift your Windows Embedded platform to use Qt, you’ve got one of three choices:

Windows Embedded Compact 7.0
Aliases WinCE7, WinEC7
Release date March 2011
MS tool version Visual Studio 2008
Qt version Up to Qt 5.6 LTS (Long Term Support)
Architectures supported x86, ARMv4+ (and derivatives)


Windows Embedded Compact 2013
Aliases WinEC2013
Release date June 2013
MS tool version Visual Studio 2012 (2013/2015 x86 only)
Qt version Qt 5.6 LTS (Long Term Support)
Architectures supported x86, ARMv7T2 (and derivatives)


Windows 10 IoT
Release date July 2015
MS tool version Visual Studio 2015
Qt version Qt 5.7
Architectures supported x86 (all variants), ARM (Mobile Enterprise and Core)


What’s the fine print? Like many things in life, no choice is perfect.

  • WinCE7 requires you to be using Qt 5.6 or earlier. But if you’ve got a WinCE7-based project already, this will certainly be the path of least resistance. KDAB has done the necessary work in Qt 5.6 to support WinCE7.
  • WinEC2013 on ARM requires Visual Studio 2012 for the right cross-compiler, and you’ll be using Qt 5.6. Unfortunately, you can’t use the more modern compilers in VS2013 or VS2015. x86 compiling should work on Visual Studio 2012-2015, although that highly limits your embedded target hardware. Similar to WinCE7, our changes to Qt 5.6 for WinEC2013 support are upstream.
  • Windows 10 IoT is still a bit of a moving target, but the Qt Company will be adding experimental support for it to Qt 5.7. If you don’t want to be building against an experimental drop, you may be better off sticking with one of the earlier two options.

Undertaking a move from a Windows-native UX framework to a Qt-based one isn’t for the faint of heart but it can be your important first step to making your application platform independent. (And it’s something that we at KDAB have a lot of experience doing should you need a bit of help.)

Likewise, getting all the right components, builds, compilers, libraries together for a solid tool chain isn’t supported out-of-the-box by anyone. We’re hoping to solve this problem in a better fashion. We’re working with Toradex—one of the world’s leading providers of windows embedded based Systems on Chip—on providing a Windows SOC with pre-built binaries and Qt installers. It’s not done yet, but keep watching this space for breaking news.

Any other Windows + Qt questions? Good tips or tricks? Post them in the comments!

The post Windows Dressing appeared first on KDAB.

Call for Papers for QtCon


KDAB has come together with KDE Akademy, Qt Contributors Summit, FSFE Summit and VideoLAN DevDays to create QtCon 2016, Sept 1 – 4, 2016. On Sept 1st there will be a day of Training from KDAB with eight great trainings to choose from, including three brand new trainings:

  • Introduction to Qt 3D
  • A training on CMake
  • Beyond code – Improved Quality through User Centric Development

The conference runs from Sept 2 – 4. There will be talks, workshops, BOFs and meetings as well as social events. KDE BOFS will be held from Monday 5th to Thursday 8th elsewhere in Berlin.

This brings a difference to the Call for Papers you might be familiar with. The reason is that we want presentations, workshop, BOFs etc. that cater to both developers and end users in each of the communities.

We would like to see top class technical presentations on developing Qt, as well as presentations on using Qt. We will be looking for presentations around the technical internals of VLC as well as the challenges of integrating it into your Qt applications. We welcome technical talks on free software but also more general presentations about free software in business, for example, or understanding software licenses. We are also looking for talks on UI design, and ideas for discussions groups, BOFs and workshops for both internal community member attendance and open attendance.

Maybe you have something else you’d like to propose along these lines, not forgetting talks that non-developers will find interesting. Find out more and submit your papers here

The post Call for Papers for QtCon appeared first on KDAB.

Eight Golden Rules: Rule 6 - Permit Easy Reversal of Actions

In this next blog post, we will explore the sixth rule of Ben Shneiderman's Eight Golden Rules of Interface Design. This rule is for designers to permit easy reversal of actions. Shneiderman explains this rule as the following,

“As much as possible, actions should be reversible. This feature relieves anxiety, since the user knows that errors can be undone, and encourages exploration of unfamiliar options. The units of reversibility may be a single action, a data-entry task, or a complete group of actions, such as entry of a name-address block.”1

Three Steps to a Successful Embedded Product

by Pejman Kalkhoran, Boundary Devices [Qt Technology Partner] (Qt Blog)

Developing an embedded product requires three main steps: selection of the proper hardware platform, operating system selection/setup, and User Interface (UI) development.  All three of these steps are very closely tied together and have a significant impact on time-to-market, project costs, and the overall quality of the product.  It is critical to select the proper hardware platform that also has excellent operating system support as well as the proper UI tools. This post dives into each of these steps and how it will impact the overall project.

1. Choose Your Hardware Platform

Selecting the proper hardware platform is the first step in the embedded product process and can have a substantial effect on the overall costs of the project in terms of unit cost as well as development time. Some important questions to ask in the selection process are:

  • Is there a stable supply chain/guaranteed longevity/availability? If the hardware that is selected is no longer available in 6 months, all of the development time will be wasted causing substantial delays in the project and significant cost.
  • Is it a high quality product? Many designs are not done with best practices in mind which can cause severe headaches in the future due to device failures. Having to recall products tarnishes the brand and has a very high cost associated with replacement.
  • Is there flexibility to provide easy upgrade paths that reduce development time/cost for future revisions?

A variety of integration options are available including Single Board Computers (SBC), System-on-Modules (SOM) and custom designs.

The SBC option is typically a fully completed design that requires a display and power supply. SBCs can be pre-FCC certified meaning that users do not need to worry about certification issues. Some SBC options can be cost-reduced by de-populating components that are not required in production.

Nitrogen6_MAX: High-end Embedded single board computer based on the NXP/Freescale i.MX6 Quad Processor. Kit includes 5V Power Supply, 4GB microSD card with Linux OS, and Serial Console Cable.

The System-on-Module provides flexibility for those who have specific IP or circuitry that they would like to include on their carrier board. The SOM contains the CPU, memory, flash, and power supplies. The rest of the circuitry is designed into the carrier board.

The final hardware option is to hire a specialist company to design a semi-custom board to meet the exact specifications of the project. In production, these solutions will be the lowest cost option because they are designed for exactly what the project requires.

2. Select a Trusted Operating System

Having a stable, high quality operating system reduces development time and helps to get to market quicker. A poor quality operating system can waste software resources due to time spent fixing bugs and also creates potential product reliability issues in the future. Selecting from industry leading operating system options such as Android 5.0, Yocto, Ubuntu, QNX, CE7/CE2013, and Buildroot will reduce the risk of these issues.

3. Create Your UI

The third and final piece of the puzzle is the user interface. One of the most complex and time-consuming elements of an embedded project is the UI development.  By utilizing a known, tested UI development tool, embedded products statistically get completed faster, which accelerates time-to-market and reduces development costs.

On hardware (such as that from Boundary Devices) that supports Qt for Device Creation, it is possible to download the IDE and start developing within minutes.

To sum it all up…

When embarking on a new embedded project, take care to select proven hardware platforms and operating systems and make sure that your partners have the experience and capabilities to see you through the entire project. Having a close association with Qt will almost certainly give them (and you) a head start. As a Qt Technology Partner, Boundary Devices can offer you exactly that.

You can contact me here:

About the Guest Blogger: Pejman is a partner at Boundary Devices and has been involved in hundreds of embedded projects – from design to manufacturing to software support.

The post Three Steps to a Successful Embedded Product appeared first on Qt Blog.

Tickets are live for foss-north

I’ve written about foss-north earlier. From now, tickets are available. What we are looking at is a free and open source one day conference in Gothenburg. Great speakers already now, and the CfP isn’t even closed.


Of course you all want to visit Gothenburg in the early summer and enjoy a day of great speakers and great company. You are all very welcome!

Media Manager for Automotive Infotainment (Part 2 of 4)

Part 2 Indexing and Tagging Media

This is the second of four blog posts about media manager components. In the first blog post we discussed the goals and a general architecture for our media manager. In today’s installation, we will show how to address some of the challenges when multiple users bring devices into the car.

Cutelyst 0.11.0 released!

Cutelyst the Qt web framework just got a new release, I was planning to do this a while back, but you know we always want to put in a few more changes and time to do that is limited.

I was also interested in seeing if the improvements in Qt 5.6 would result in better benchmark tests but they didn't, the hello world test app is probably too simple for the QString improvements to be noticed, a real world application using Grantlee views, Sql and more user data might show some difference. Still, compared to 0.10.0 Cutelyst is benchmarking the same even tho there were some small improvements.

The most important changes of this release were:

  • View::Email allows for sending emails using data provided on the stash, being able to chain the rendering of the email to another Cutelyst::View so for example you can have your email template in Grantlee format which gets rendered and sent via email (requires simple-mail-qt which is a fork of SmtpClient-for-Qt with a sane API, the View::Email hides simple-mail-qt API)
  • Utils::Sql provides a set of functions to be used with QSql classes, most importantly are serializing QSqlQuery to QVariantList of QVariantMap (or Hashes), allowing for accessing the query data on a View, and the preparedSqlQuery() method which comes with a macro CPreparedSqlQuery, that is a lambda that keeps your prepared statement into a static QSqlQuery, this avoids the need of QSqlQuery pointers to keep the prepared queries around (which are a boost for performance)
  • A macro CActionFor which resolves the Action into a static Action * object inside a lambda removing the need to keep resolving a name to an Action
  • Unit tests at the moment a very limited testing is done, but Header class has nearly 100% of coverage now
  • Upload parser got a fix to properly find the multipart boundary, spotted due Qt client sending boundaries a bit different from Chrome and FF, this also resulted in the removal of QRegularExpression to match the boundary part on the header with a simple search that is 5 times faster
  • Require Qt 5.5 (this allows for removal of workaround for QJson::fromHash and allows for the use of Q_ENUM and qCInfo)
  • Fixed crashes, and a memory leak is Stats where enabled
  • Improved usage of QStringLiteral and QLatin1String with clazy help
  • Added CMake support for setting the plugins install directory
  • Added more 'const' and 'auto'
  • Removed uwsgi --cutelyst-reload option which never worked and can be replaced by --touch-reload and --lazy
  • Improvements and fixes on cutelyst command line tool
  • Many small bugs fixed

The Cutelyst website is powered by Cutelyst and CMlyst which is a CMS, at the moment porting CMlyst from QSettings to sqlite is on my TODO list but only when I figure out why out of the blue I get a "database locked" even if no other query is running (and yes I tried query.finish()), once I figure that out I'll make a new CMlyst release.

Download here.

Have fun!

Qt Creator 4.0 Beta released

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

As announced earlier this year, starting with this release Qt Creator will be available under commercial license terms and GPLv3 (with exceptions). At the same time we are making the following features available under open source, which were previously only available under commercial license terms. So, if you didn’t know them, make sure to check them out!

Clang Static Analyzer Integration

Find problems in C, C++ and Objective-C programs. (Documentation)

Autotest Integration (Experimental)

Easily run autotests from your project and get the results presented in a friendly way. (Documentation)

Extended QML Profiler

Profile pixmap cache usage, scene graph performance, JavaScript memory usage and input events of QML applications. (Documentation)


We also started implementing a flat theme for which Diana presented the concepts already a year ago. This is still work in progress, but you can see for yourself by switching to the new theme “Default Flat” in Tools > Options > Environment > Interface.

Users of CMake will find that we improved the workflow for CMake-based projects. CMake is now triggered automatically when necessary, which makes for a much nicer user experience. Kit settings like the Qt version or tool chain used are automatically configured in CMake build directories, removing one more obstacle for users. Projects mode now features a UI to change the CMake configuration for a build directory. Qt Creator will no longer create CMake build directories before the project is built. This makes for a much tidier work environment, especially when users only want to study source code using the CMake build system.

If you wonder where Analyze mode has gone: It is now merged into Debug mode. There is not much of a difference really. Merging them removes complexity code-wise and user-interface-wise, and it actually opens up some flexibility for us for the future.

There were many more improvements, and more features added, please check our change log for details.

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

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

Implementing OpenPGP and S/MIME Cryptography in Trojita

Are you interested in cryptography, either as a user or as a developer? Read on -- this blogpost talks about some of the UI choices we made, as well as about the technical challenges of working with the existing crypto libraries.

The next version of Trojitá, a fast e-mail client, will support working with encrypted and signed messages. Thanks to Stephan Platz for implementing this during the Google Summer of Code project. If you are impatient, just install the trojita-nightly package and check it out today.

Here's how a signed message looks like in a typical scenario:

A random OpenPGP-signed e-mail

Some other e-mail clients show a yellow semi-warning icon when showing a message with an unknown or unrecognized key. In my opinion, that isn't a great design choice. If I as an attacker wanted to get rid of the warning, I could just as well sign a faked but unsigned e-mail message. This message is signed by something, so we should probably not make this situation appear less secure than as if the e-mail was not signed at all.

(Careful readers might start thinking about maintaining a peristant key association database based on the observed traffic patterns. We are aware of the upstream initiative within the GnuPG project, especially the TOFU, Trust On First Use, trust model. It is a pretty fresh code not available in major distributions yet, but it's definitely something to watch and evaluate in future.)

Key management, assigning trust etc. is something which is outside of scope for an e-mail client like Trojitá. We might add some buttons for key retrieval and launching a key management application of your choice, such as Kleopatra, but we are definitely not in the business of "real" key management, cross-signatures, defining trust, etc. What we do instead is working with your system's configuration and showing the results based on whether GnuPG thinks that you trust this signature. That's when we are happy to show a nice green padlock to you:

Mail with a trusted signature

We are also making a bunch of sanity checks when it comes to signatures. For example, it is important to verify that the sender of an e-mail which you are reading has an e-mail which matches the identity of the key holder -- in other words, is the guy who sent the e-mail and the one who made the signature the same person?

If not, it would be possible for your co-worker (who you already trust) to write an e-mail message to you with a faked From header pretending to be your boss. The body of a message is signed by your colleague with his valid key, so if you forget to check the e-mail addresses, you are screwed -- and that's why Trojitá handles this for you:

Something fishy is going on!

In some environments, S/MIME signatures using traditional X.509 certificates are more common than the OpenPGP (aka PGP, aka GPG). Trojitá supports them all just as easily. Here is what happens when we are curious and decide to drill down to details about the certificate chain:

All the glory details about an X.509 trust chain

Encrypted messages are of course supported, too:

An ancrypted message

We had to start somewhere, so right now, Trojitá supports only read-only operations such as signature verification and decrypting of messages. It is not yet possible to sign and encrypt new messages; that's something which will be implemented in near future (and patches are welcome for sure).

Technical details

Originally, we were planning to use the QCA2 library because it provides a stand-alone Qt wrapper over a pluggable set of cryptography backends. The API interface was very convenient for a Qt application such as Trojitá, with native support for Qt's signals/slots and asynchronous operation implemented in a background thread. However, it turned out that its support for GnuPG, a free-software implementation of the OpenPGP protocol, leaves much to be desired. It does not really support the concept of PGP's Web of Trust, and therefore it doesn't report back how trustworthy the sender is. This means that there woldn't be any green padlock with QCA. The library was also really slow during certain operations -- including retrieval of a single key from a keystore. It just isn't acceptable to wait 16 seconds when verifying a signature, so we had to go looking for something else.

Compared to the QCA, the GpgME++ library lives on a lower level. Its Qt integration is limited to working with QByteArray classes as buffers for gpgme's operation. There is some support for integrating with Qt's event loop, but we were warned not to use it because it's apparently deprecated code which will be removed soon.

The gpgme library supports some level of asynchronous operation, but it is a bit limited. Ultimately, someone has to do the work and consume the CPU cycles for all the crypto operations and/or at least communication to the GPG Agent in the background. These operations can take a substantial amount of time, so we cannot do that in the GUI thread (unless we wanted to reuse that discouraged event loop integration). We could use the asynchronous operations along with a call to gpgme_wait in a single background thread, but that would require maintaining our own dedicated crypto thread and coming up with a way to dispatch the results of each operation to the original requester. That is certainly doable, but in the end, it was a bit more straightforward to look into the C++11's toolset, and reuse the std::async infrastructure for launching background tasks along with a std::future for synchronization. You can take a look at the resulting code in the src/Cryptography/GpgMe++.cpp. Who can dislike lines like task.wait_for(std::chrono::duration_values::zero()) == std::future_status::timeout? :)

Finally, let me provide credit where credit is due. Stephan Platz worked on this feature during his GSoC term, and he implemented the core infrastructure around which the whole feature is built. That was the crucial point and his initial design has survived into the current implementation despite the fact that the crypto backend has changed and a lot of code was refactored.

Another big thank you goes to the GnuPG and GpgME developers who provide a nice library which works not just with OpenPGP, but also with the traditional X.509 (S/MIME) certificates. The same has to be said about the developers behind the GpgME++ library which is a C++ wrapper around GpgME with roots in the KDEPIM software stack, and also something which will one day probably move to GpgME proper. The KDE ties are still visible, and Andre Heinecke was kind enough to review our implementation for obvious screwups in how we use it. Thanks!