Qt Quick without a GPU: i.MX6 ULL


With the introduction of the Qt Quick software renderer it became possible to use Qt Quick on devices without a GPU. We investigated how viable this option is on a lower end device, particularly the NXP i.MX6 ULL. It turns out that with some (partially not yet integrated) patches developed by KDAB and The Qt Company, the performance is very competitive. Even smooth video playback (with at least half-size VGA resolution) can be done by using the PXP engine on the i.MX6 ULL.

continue reading

The post Qt Quick without a GPU: i.MX6 ULL appeared first on KDAB.

Swift 4.0 is Ready

We’re excited to announce that Swift 4.0 has reached full release status. The packages can be downloaded from the releases page and a full list of new features can be found in the 4.0 changelog.

We encourage everyone to get the new build and try it out, and give us feedback on our latest release.

Qt Creator 4.6 RC released

We are happy to announce the release of Qt Creator 4.6 RC!

Since the beta release we have been busy with bug fixing. Please refer to the beta blog post and our change log for an overview of what is new in Qt Creator 4.6. As always this is a final call for feedback from you before we release 4.6.0, so we would be happy to hear from you on our bug tracker, the mailing list, or on IRC.

Get Qt Creator 4.6 RC

The opensource version is available on the Qt download page, and you find commercially licensed packages on the Qt Account Portal. Qt Creator 4.6 RC is also available under Preview > Qt Creator 4.6.0-rc1 in the online installer, as an update to the beta release. Please post issues in our bug tracker. You can also find us on IRC on #qt-creator on chat.freenode.net, and on the Qt Creator mailing list.

The post Qt Creator 4.6 RC released appeared first on Qt Blog.

Qt used to demonstrate KNX IoT possibilities at ISE and L+B fairs

KNX Introduction

In its more than 25 years of history, KNX has an unrivaled track record of guaranteeing long-term support of automation solutions in any type of building.
Based on the KNX standard, building automation can be realized in a reliable, interoperable and extendable way: devices from over 400 manufacturers work together in a very stable distributed environment without a single point of failure. The current ecosystem is physically easy to install and logically configurable with one single tool, ETS™.

IoT is not an easy solution with cross-vendor support yet

Complexity has increased, reliability and interoperability are however still not guaranteed

  • Many solutions are available that cover just one single use case (voice control, internet connected doorbell, lights and room temperature regulator controllable by App, …).
  • To try to connect the different services provided by devices in a reliable way is not trivial.
  • In many cases, the correct functioning of devices depends on internet connection.
  • Customized software integrations can break upon every software update and is very complex to secure. Reliability and stability is not guaranteed over a longer period of time, a must for building automation.
  • Integration may depend on cloud services managed by 3rd party companies, out of control of the end user and with a specific business case in mind.

KNX and IoT

There are numerous good solutions from KNX manufactures to connect KNX to higher-level IoT systems already today. The internet side of these products is however not standardized or is created to match specific use cases.

As announced in 2016, as a first step towards standardizing the internet side of such KNX IoT gateways, KNX Association published the KNX web services specifications to allow aligning gateways to the existing web services protocols oBIX, OPC/UA, and BACnet web services.

Adding advantages from KNX to loT

As a second step in the KNX IoT project, KNX now wishes to make the key KNX advantages of interoperability, reliability, and extendibility also available on the IoT level. To demonstrate the goals, a demonstrator was created with Qt technology.

Qt KNX module

Qt KNX implements the client side of a connection between a client and a KNXnet/IP server. This connection enables sending messages to the KNX bus and controlling the functionalities of the KNX devices. The Qt KNX module is currently available as a Technology Preview as part of Qt for Automation add-ons. More details on the Qt KNX module can be found here: https://resources.qt.io/qt-knx/. Documentation: http://doc.qt.io/QtKNX/qtknx-overview.html/

Qt demonstrator

For the new KNX IoT solution, it is crucial that all device types can seamlessly tap into the communication. The demonstrator includes a representation of all possible involved device types. The goal is to explain the advantages of each type towards the overall solution.





The demonstrated devices include:

  • KNX devices on twisted pair and radio frequency.
  • NXP development boards with Thread group network stack, integrated with the KNX application layer
  • RaspberryPi devices representing capable devices and cloud server
  • A Linux desktop

The setup underlines the key points of the KNX IoT solution:

  • Semantic interoperability
  • A distributed solution containing both Classic and IoT device/services
  • Integration of KNX Classic devices
  • Integration of Fairhair group network devices based on Thread as example for constrained field bus level network
  • High availability and eventual consistency, demonstrating how the distributed solution copes with device and network failures

Demo cases

  1. Data is synchronized in real-time. Light color can be changed by any of the components, change is visible on all others
  2. The system still works when disabling components, demonstration of how parts recover
  3. The system works when the internet connection is down, requests for color changes can still be made from all sides (execution will not be immediate on all sides, but as soon as the broken link in the network is restored)
  4. Show data-driven messages
  5. Show semantic model
  6. Show integration with Google drive


The Qt framework was chosen to easily create this setup for several reasons:

  • Single codebase usable for RaspberryPi graphical solution + Android + Linux desktop
  • Low effort to create a visually appealing interface, including animations and high framerate for smooth animations and movements within the frontend.
  • Network libraries giving a better abstraction for networking
  • Qt is also used for the authentication against the Google API
  • Qt KNX is used to connect to KNXnet/IP to interact with the devices on Twisted pair and radio frequency


The KNX IoT solution will lower the barrier to access KNX as part of the Internet of Things. The aim is to reduce the knowledge required and open the current KNX ecosystem to non-KNX IT specialists through ‘out-of-the-box’ operation, while still allowing advanced configuration and adaption by specialists.

The KNX IoT solution is defined in partnership with key KNX manufacturers and standardization bodies (like Fairhair and the Thread group). KNX is also working on proofs of concept to validate the solutions. Qt makes it possible to concentrate on the key points and keep the code clear from system-specific implementations in these proofs of concepts.

Leveraging standards ensures that the value of KNX products is increased and long-term support can be guaranteed in a constantly changing IoT world. KNX has the advantage of a large KNX install base, which allows drawing on a wealth of experience that will help successfully extending the KNX integration into the Internet of Things.

More details on the KNX IoT project can be found here: https://www.knx.org/knx-en/Landing-Pages/KNX-IoT/

“The Qt Company is exhibiting at Light+Building 2018 at Hall 8.0 F98 as part of the KNX member booth and our experts will be on hand to discuss building cost and time efficient building automation applications. “

The post Qt used to demonstrate KNX IoT possibilities at ISE and L+B fairs appeared first on Qt Blog.

Qt Creator 4.5.2 released

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

This release includes a workaround for an issue in Qt which makes Qt Creator’s summary progress bar and some other controls disappear (QTCREATORBUG-19716).

Get Qt Creator 4.5.2

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

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

qutebrowser v1.2.0 released!

I'm happy to announce that I just released qutebrowser v1.2.0!

qutebrowser is a keyboard driven browser with a vim-like, minimalistic interface. It's written using PyQt and cross-platform.

This release comes with a long changelog, but the most interesting changes are probably initial support for per-domain settings (I've had …

Qt Contributors’ Summit 2018


Contributors, Mark your calendars!

11th and 12th June 2018

And the location is Oslo, Norway.

Oslo in June is a beautiful place to be, but the best part is that you will meet all the Qt Contributors!

The Qt Contributors’ Summit is an annual event open to anyone who has contributed toward the Qt project in the past year. Contributions can include code, helping on the forum, maintaining the wiki, or any other form of moving the Qt project forward. We are also happy to have advanced Qt users at the event, as there can never be too much user feedback.

For the past two years the Qt Contributors’ Summit has been run as part of bigger events. In 2016 we co-located with QtCon and last year with Qt World Summit. This year we want to have Qt Contributors’ Summit as it’s own event which focuses again more on the core Qt community.

Qt Contributors’ Summit is traditionally run as an unconference, participants bring their topics to the event and they are presented and discussed. We are thinking of changing the format somewhat, so that the topics can be prepared a bit more in advance and we could also have some hands on work ongoing at the event itself.

As always the event will be free of charge, but we will have a registration page, so we can prepare better.

If you are interested in sponsoring the event, please get in touch with me, we are more than happy to have help in making Qt Contributors’ Summit a great event.

I’m looking forward to seeing many of you in June in Oslo!

The post Qt Contributors’ Summit 2018 appeared first on Qt Blog.

Slate: A Basic Pixel Art Editor Built with Qt Quick

I loved video games as a kid. Pokémon Blue and Wario Land on GameBoy. On the SNES I played SimCity, The Lost Vikings, Cannon Fodder, Super Mario World, Axelay… probably more that I can’t remember. Then there were the old Windows 95 games on PC, PlayStation, Xbox… ah, good times. Video games were the reason I started learning how to program: I wanted to make my own games. To this day (at least a decade later) I’m still working on games in my spare time, hoping to one day release a game that others will enjoy as much as I enjoy the games I play.

The current one I’m working on is a 2D isometric turn-based RPG. The artwork is all pixel art, as it’s easy to create, and, as a bonus, I don’t have to worry about scaling/high DPI! While working on the game, I decided that I should find a tool for creating tilesets. None of the tools I looked at had what I was after, so I thought: “how hard could it be to create my own?”

As it turns out, it wasn’t that hard, and it was also really fun and rewarding. It has also branched out beyond just creating tilesets, and is now a more general editor that has support for editing images directly and using layers. Here’s a GIF of it in action (apologies in advance for the compression in the colour picker):


It’s still in alpha, but it’s at a stage where I’ve been happily using it to create the artwork for my game, so I consider it usable.

Taken from its GitHub page:

“Slate was built for pixel art, and its goal is to simplify the creation of sprites and tilesets by offering a user-friendly, customisable interface.”

Being a desktop application built with Qt Quick Controls 2, I figured that it might be an interesting example for others to read about. In this post, I’m going to briefly discuss how I implemented Slate’s user interface and auto tests.

Visual Structure

Slate is simple. My goal when creating it was to have something that was fun to work on and easy to maintain.

To that end, each instance of Slate can only have one image open at a time. The canvas for the image takes up the most of the screen:




Currently, all of the panels are collapsible, but fixed to the right side of the window. I know some people like dockable windows, but in the spirit of keeping it simple, I went with this approach. Each panel is represented by Panel.qml:

import QtQuick 2.6
import QtQuick.Layouts 1.1
import QtQuick.Controls 2.0

import App 1.0

import "." as Ui

Page {
    id: root
    objectName: "panel"
    background: Rectangle {
        color: Ui.CanvasColours.panelColour

    property bool expanded: true
    property Popup settingsPopup: null

    header: RowLayout {
        spacing: 0

        Label {
            text: root.title
            font.bold: true

            Layout.leftMargin: 16

        Item {
            Layout.fillWidth: true

        ToolButton {
            objectName: root.objectName + "SettingsToolButton"
            text: "\uf013"
            font.family: "FontAwesome"
            focusPolicy: Qt.NoFocus
            visible: settingsPopup

            Layout.preferredWidth: implicitHeight

            onClicked: settingsPopup.open()

        ToolButton {
            objectName: root.objectName + "HideShowToolButton"
            text: expanded ? "\uf146" : "\uf0fe"
            font.family: "FontAwesome"
            focusPolicy: Qt.NoFocus

            Layout.leftMargin: -8
            Layout.preferredWidth: implicitHeight

            onClicked: expanded = !expanded

Panel itself is a Page. I chose this type because it allows me to conveniently specify a header that contains the title of the panel and its buttons. Each panel can be collapsed, and can also provide some panel-specific settings that are modified through a popup.



Common tools and operations are in the toolbar at the top of the window, with the complete set being available in the menu bar:

import Qt.labs.platform 1.0 as Platform

import App 1.0

Platform.MenuBar {
    property ImageCanvas canvas
    property ProjectManager projectManager
    property Project project: projectManager.project
    property int projectType: project ? project.type : 0
    readonly property bool isImageProjectType: projectType === Project.ImageType || projectType === Project.LayeredImageType

    property var canvasSizePopup
    property var imageSizePopup

    // ...

    Platform.Menu {
        id: editMenu
        objectName: "editMenu"
        title: qsTr("Edit")

        Platform.MenuItem {
            objectName: "undoMenuButton"
            text: qsTr("Undo")
            onTriggered: project.undoStack.undo()
            enabled: project && project.undoStack.canUndo

        Platform.MenuItem {
            objectName: "redoMenuButton"
            text: qsTr("Redo")
            onTriggered: project.undoStack.redo()
            enabled: project && project.undoStack.canRedo

        Platform.MenuSeparator {}

        Platform.MenuItem {
            objectName: "copyMenuButton"
            text: qsTr("Copy")
            onTriggered: canvas.copySelection()
            enabled: isImageProjectType && canvas && canvas.hasSelection

        Platform.MenuItem {
            objectName: "pasteMenuButton"
            text: qsTr("Paste")
            onTriggered: canvas.paste()
            enabled: isImageProjectType && canvas

        // ...
    // ...

As Slate has been developed against the latest Qt Quick Controls 2 versions, it recently started using native menu bars on all platforms. However, it was previously using non-native menus on Windows until the support was added. I mention this because I feel like it could be a useful example; not only for how to have native controls on some platforms, and non-native controls on others, but also to demonstrate how to use file selectors for situations like this in general. To learn more, see the repo as of this commit; specifically, this version of MenuBar.qml is native, and this one is a non-native alternative for Windows.



The ToolBar is based on the ToolBar control:

import QtQuick 2.6
import QtQuick.Controls 2.1

import App 1.0

import "." as Ui

ToolBar {
    id: root
    objectName: "iconToolBar"

    // ...

    Row {
        id: toolbarRow
        enabled: canvas
        anchors.fill: parent
        // Make sure that we don't end up on a sub-pixel position.
        anchors.leftMargin: Math.round(toolSeparator.implicitWidth / 2)

        ToolButton {
            id: canvasSizeButton
            objectName: "canvasSizeButton"
            enabled: project && project.loaded
            hoverEnabled: true
            focusPolicy: Qt.NoFocus

            icon.source: "qrc:/images/change-canvas-size.png"

            ToolTip.text: qsTr("Change the size of the canvas")
            ToolTip.visible: hovered && !canvasSizePopup.visible

            onClicked: canvasSizePopup.open()

        ToolButton {
            id: imageSizeButton
            objectName: "imageSizeButton"
            enabled: project && project.loaded && !isTilesetProject
            hoverEnabled: true
            focusPolicy: Qt.NoFocus

            icon.source: "qrc:/images/change-image-size.png"

            ToolTip.text: qsTr("Change the size of the image")
            ToolTip.visible: hovered && !imageSizePopup.visible

            onClicked: imageSizePopup.open()

        ToolSeparator {}

        Row {
            spacing: 5

            Ui.IconToolButton {
                objectName: "undoButton"
                text: "\uf0e2"
                enabled: project && project.undoStack.canUndo
                hoverEnabled: true

                ToolTip.text: qsTr("Undo the last canvas operation")
                ToolTip.visible: hovered

                onClicked: project.undoStack.undo()

            Ui.IconToolButton {
                objectName: "redoButton"
                text: "\uf01e"
                enabled: project && project.undoStack.canRedo
                hoverEnabled: true

                ToolTip.text: qsTr("Redo the last undone canvas operation")
                ToolTip.visible: hovered

                onClicked: project.undoStack.redo()

            ToolSeparator {}
        // ...

It is a mix of ToolButtons using images for icons and a custom IconToolButton that is simply a ToolButton that sets FontAwesome as its font family for convenience.


All of the shortcuts are defined in Shortcuts.qml:

import QtQuick 2.6

import App 1.0

Item {
    objectName: "shortcuts"

    // ...

    Shortcut {
        objectName: "redoShortcut"
        sequence: settings.redoShortcut
        onActivated: project.undoStack.redo()
        enabled: canvasHasActiveFocus && project && project.undoStack.canRedo

    Shortcut {
        objectName: "copyShortcut"
        sequence: StandardKey.Copy
        onActivated: canvas.copySelection()
        enabled: isImageProjectType && canvasHasActiveFocus && canvas.hasSelection

    Shortcut {
        objectName: "pasteShortcut"
        sequence: StandardKey.Paste
        onActivated: canvas.paste()
        enabled: isImageProjectType && canvasHasActiveFocus

    // ...

I started writing Slate before Action was introduced, and haven’t bothered to clean this up yet. Ideally, each of these shortcuts would be an action in MenuBar.qml, instead of being defined in both Shortcuts.qml and MenuBar.qml.

Each shortcut’s key sequence is stored in ApplicationSettings, as they are configurable. Below is a screenshot of the shortcuts tab of OptionsDialog:


Each shortcut there is represented by a ShortcutRow item. KeySequenceEditor takes care of the actual key editing.


To match its name, Slate uses the Material style‘s dark theme. I find dark themes more gentle on the eyes, and, in my opinion, the Material style is the best looking style in Qt Quick Controls 2.

In some places I’ve experimented with supporting other styles, such as the Universal style. I did so using file selectors.

When adding custom UI elements, such as the current layer indicator in the Layer panel, I’ve made sure to use the accent colour from the active style:


To do this, I use a CanvasColours singleton. The default implementation is for the default style (again, just experimenting), with other styles having their own implementation of the singleton in their specific file selector directories. The Material style implementation is here. Notice that it uses Material.accent.


I take comfort in auto tests. They’re a great reassurance that I haven’t screwed everything up. I try to add tests for every new feature. Sometimes I get lazy, but in general I think the coverage is pretty good.

Gritty Details

My goal with the auto tests is to try as much as possible to emulate the workflow that a user would employ. This means clicking buttons instead of just calling the C++ function that the button would have called.

The test case itself inherits from TestHelper, which provides helper functions for common tasks. Here’s an example of a test:

void tst_App::disableToolsWhenLayerHidden()
    QVERIFY2(createNewLayeredImageProject(), failureMessage);

    // The cursor should be normal.
    setCursorPosInScenePixels(0, 0);
    QTest::mouseMove(window, cursorWindowPos);
    QCOMPARE(window->cursor().shape(), Qt::BlankCursor);

    QQuickItem *layer1Delegate = nullptr;
    QVERIFY2(verifyLayerName("Layer 1", &layer1Delegate), failureMessage);
    QQuickItem *layer1VisibilityCheckBox = layer1Delegate->findChild<QQuickItem*>("layerVisibilityCheckBox");

    const QVector<ImageCanvas::Tool> tools {
        ImageCanvas::CropTool TODO: not implemented yet*/

    foreach (ImageCanvas::Tool tool, tools) {
        // Hide the layer.
        mouseEventOnCentre(layer1VisibilityCheckBox, MouseClick);
        QCOMPARE(layeredImageProject->currentLayer()->isVisible(), false);

        // Switch tool.
        QVERIFY2(switchTool(tool), failureMessage);

        // The cursor should be disabled for each tool.
        setCursorPosInScenePixels(0, 0);
        QTest::mouseMove(window, cursorWindowPos);
        if (window->cursor().shape() != Qt::ForbiddenCursor) {
            QString message;
            QDebug debug(&message);
            debug.nospace() << "Expected Qt::ForbiddenCursor for tool " << tool << ", but got " << window->cursor().shape();

        // Make the layer visible again.
        mouseEventOnCentre(layer1VisibilityCheckBox, MouseClick);
        QCOMPARE(layeredImageProject->currentLayer()->isVisible(), true);

        // The cursor should not be ForbiddenCursor now.
        QVERIFY(window->cursor().shape() != Qt::ForbiddenCursor);

    // Hide the layer.
    mouseEventOnCentre(layer1VisibilityCheckBox, MouseClick);
    QCOMPARE(layeredImageProject->currentLayer()->isVisible(), false);

    // Ensure that we can't actually do anything when the cursor is disabled.
    QVERIFY2(switchTool(ImageCanvas::PenTool), failureMessage);
    setCursorPosInScenePixels(10, 10);
    QTest::mouseMove(window, cursorWindowPos);
    QTest::mouseClick(window, Qt::LeftButton, Qt::NoModifier, cursorWindowPos);
    QCOMPARE(layeredImageProject->currentLayer()->image()->pixelColor(10, 10), QColor(Qt::white));

One important thing that I think is worth mentioning is the approach to verifying the success of helper functions. QVERIFY and friends do not work outside of test functions. What you’ll see if you try to cause a failure outside of a test function invoked by the test framework is that the failure is printed in the test’s output, but does not prevent further execution of the test (it can’t, because the macros just return early, which would bring control back to the test function itself). This is a subtle issue that I think deserves some attention.

To get around this, I’ve copied the macros and removed their “Q” prefixes. As an example, here’s VERIFY:

#define VERIFY(statement) \
do { \
    if (!static_cast<bool>(statement)) { \
        failureMessage = #statement; \
        return false; \
    } \
} while (false)

All helper functions must use these macros. It’s not as good as having the code within the test functions themselves, because I don’t get useful line numbers (the failure points to the invocation of the function, not the position of the failure in the helper function). However, I can make up for this by providing better failure messages in the helper functions, and I’d rather this than having to duplicate the code. Using the first line of the test above as an example:

QVERIFY2(createNewLayeredImageProject(), failureMessage);

If a failure were to occur on this line in the createNewLayeredImageProject() helper:

VERIFY(nameTextField->property("text").toString() == QLatin1String("Layer 1"));

I would receive this failure message:

FAIL! : tst_App::disableToolsWhenLayerHidden() 'createNewLayeredImageProject()' returned FALSE. (nameTextField->property("text").toString() == QLatin1String("Layer 1"))
..\..\slate\tests\tst_app.cpp(3203) : failure location

As mentioned in the bug report, QCOMPARE can’t be easily duplicated, so I also can’t see what the actual value is, just the expected value.

If the QVERIFY2 above fails, execution eventually returns to cleanup(), where the failure message is cleared in preparation for the next test.

Project Structure

I took the lazy man’s approach to the project structure for the auto tests. Everything needed to build the application is in app.pri. That way, app.pro and tests.pro just need to include it.

… which means that all of the C++ files and resources (QML, images, etc.) are built twice! I would not recommend this, especially for larger projects (Slate is not that big, so it hasn’t bothered me yet). The standard, proper, non-lazy way of structuring a project like this is to move the application’s C++ and resources into a library, and then use that in the application and tests. One day I’ll do it the proper way, but so far I’ve been much more interested in adding cool features to my application than build systems. 🙂


Writing this application has been fun. It was also nice to dogfood Qt Quick Controls 2 in the process, as it’s helpful to be able to think like a user of the API.

In terms of things I have learned in the process, the first one that comes to mind is the undo framework.

I hope that this article was interesting. Feel free to explore the code in Slate and use it in your applications. 🙂

The post Slate: A Basic Pixel Art Editor Built with Qt Quick appeared first on Qt Blog.

Qt Customer Survey 2017

Towards the end of every year, we ask you to participate in the Qt Customer Survey. We do this to get a better understanding of your Qt use, satisfaction, and engagement.

Every year you give us helpful insights – insights we need to make better decisions. By learning more about how you use Qt and how you interact with Qt, it allows us to improve on both the product itself and how we provide customer service. We strive to better understand your likes and dislikes and identify areas where we need to make improvements – we would like to sincerely thank you for taking part in that. We are especially thankful to see a lot of valuable input to our RnD via feedback in the comment sections.

As we were analyzing and digesting your feedback, we thought it’d be interesting to share some findings with you already.

What industries are you in?

This was not an easy one to analyze – you’re using Qt for developing desktop and mobile applications, embedded systems and headless devices used on Earth and beyond, in more than 70 industries. Your use cases span from software development kits (SDK), enterprise applications, game development tools, robotics, smart homes and factories, test and measurement systems, consumer goods, automotive, healthcare lab equipment, security systems, digital TVs, and much more. In short – we’re excited to see you put Qt to such a wide use!

What is your biggest win with Qt? (Brag alert!)

‘’Ability to target multiple platforms from the same codebase – blows customers minds every time.’’

’’I feel like I hired a whole department of programming teams working for me.’’

’’Big automotive manufacturer was really happy with the results and expressed: “Is this done with Qt“. Several projects delivered quickly and with appealing results.’’

’’Our biggest win was the ability to migrate our 20+ years old C++ codebase from MFC to something _really_ modern in a continuous and quite straightforward way, improving also the development process as an additional benefit.’’

’’Impressing the bosses with a nice product that is pretty snappy and has great graphics compared to what is on the market.’’

’’With Qt, I have the flexibility to work as I need to. Qt does not lock me into anything and plays well with the “rest of the world”. I just wish it were the other way around as well.’’

’’Being able to give customers access to a full-fledged webbrowser/HTML5 experience within our product’’

’’Simultaneous Win/Mac product releases.  Modern browser js frontend talking to Qt backend.’’

’’Clean, simple API and it’s fun to work with!’’

Support for highly tailored use cases

Seems like you find some development goals more difficult to achieve than others. We provide support for several operating systems and hardware configurations, but many of you like to push the limits further. We get it, we love to play as well! Share your goals with us, chances are we’ve cleared your roadblocks many times before. We’ll get out shovels, put our backs into it and get you right back on track.

What about learning resources?

We’re happy to learn that our documentation continues to be the trusted source of information for you. However, seems like we still have some work to do on helping you use all the best practices with Qt. We’ve taken your point, and there’s something already in preparation – stay tuned for more tutorials, live and on-demand webinars and the local Qt events and meetups!

What about Qt Widgets?

A lot of you have asked us about the development of Qt Widgets. Since August 2017, the maintainership of Widgets has been transferred back to The Qt Company. This is a signal that we plan to put more resources on widgets going forward, and increase the activity level around the module in general. Rather than seeking to implement new features, the focus will be to access the already large database of bug reports and suggestions in Jira, and get the bug count down. This includes both writing patches internally, but also being more active accepting and reviewing patches from the community. With good help from the latter, we already managed to close around 250 tasks since last summer.

Showing gratitude

To show our appreciation for taking time to help us become better, we’ve had a small raffle with a few gadgets thrown in for you to pick. The winners are now informed, and the items are on their way! Hope you will enjoy your Bose QC35 headphones and Polar A370 fitness watches!

The post Qt Customer Survey 2017 appeared first on Qt Blog.

Qt 3D Studio 1.1 Released

We are happy to announce that Qt 3D Studio 1.1 has now been released. This release introduces many improvements to the user interface and introduces an improved way to define data driven UI content.

Qt 3D Studio is a design tool for creating 3D user interfaces and adding 3D content into Qt based applications.  With Qt 3D Studio you can easily define the 3D content look & feel, animations and user interface states. Please refer to earlier blog posts for more details on Qt 3D Studio functionality.

Data Inputs

As we have been gaining more feedback from the Qt 3D Studio users we have clearly seen that the way how application passes data to the user interface created with the Qt 3D Studio can be improved. To address this issue, we have created a new feature called Data Inputs. In 1.1. release this feature is a technology preview and it supports creating two types of data inputs: ranged numbers and text. Ranged numbers are mainly meant for controlling animation timelines. Text inputs can be used to modify the user interface text elements and control slide changes. For more details on how to use data inputs please refer to documentation

Qt 3D Studio Data Input

Behavior Scripts

1.1 release also introduces a technology preview of the new Behavior Scripting API which enables interacting with the runtime using QML and JavaScript. Behavior scripts can expose properties which can be used to modify the script’s behaviour without changing the script itself. Furthermore scripts can also create events which trigger user interface changes e.g. UI state changes.

Behavior scripts can be used for example to create custom animations, generate simulation data or hook custom events (e.g. keyboard control) to the user interface.

Getting started with 1.1 release

Qt 3D Studio 1.1 is now available through Qt online installer under the Tools section. Qt online installer can be obtained from Qt Download page and commercial license holders can find the packages from Qt Account. Some example projects can be found under examples folder in the installation directory. Additional examples and demo applications can be found from https://git.qt.io/public-demos/qt3dstudio repository. If you encounter issues with using Qt 3D Studio or you would like to suggest new feature please use Qt3D Studio project in the bugreports.qt.io


The post Qt 3D Studio 1.1 Released appeared first on Qt Blog.

foss-north – the count down

At this year’s foss-north event FSFE will revive the Nordic Free Software Award and the conference will host the prize ceremony. Get your tickets for a great opportunity to meet with the FOSS community, learn new things and visit Gothenburg.

It is just 9 more days left of the Call for Papers. With the help of our great sponsors we have the opportunity to transport you to our conference if you are selected to speak. Make sure to make your submission before March 11 and you are in the race.

foss-north – the count down

We are approaching the count down to foss-north 2018 – at least from an organizer perspective. This year we will be at Chalmers Conference Centre, in the centre of Gothenburg – the world’s most sociable, friendliest city. So, save the date – April 23 – and make sure to drop by.

The reason why it feels like the count down has started is that it is just 10 more days left of the Call for Papers. With the help of our great sponsors we have the opportunity to transport you to our conference if you are selected to speak. Make sure to make your submission before March 11 and you are in the race.

When moving to Chalmers we ended up with a larger venue than last year so make sure to get your ticket – and bring your friends. The saying “the more the merrier” definitely applies to FOSS conferences!

Qt 5.11 Beta1 Released

I am pleased to announce that Qt 5.11 Beta 1 is released today. Convenient online binary installers are available for trying out features coming in Qt 5.11. We will follow similar Beta process as earlier and provide multiple Beta releases via the online installer. 

For new features coming in Qt 5.11, please check the New features in Qt 5.11 wiki page and the Qt Roadmap for 2018 blog post.

After the Qt 5.11 Beta 1 released today we will push out multiple new Beta N releases using the online installer. With this approach it is easy for users to test the new features and provide feedback. During the beta phase we expect to have new Beta N releases with 1-2 weeks intervals. When the maturity has increased sufficiently we will create a release candidate of Qt 5.11. These will be made available directly via the online installer, we are not planning publish separate blogs for the subsequent beta releases and release candidate(s). In addition to binaries, source packages of each beta release are of course also available for those who prefer to build themselves.

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

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

The post Qt 5.11 Beta1 Released appeared first on Qt Blog.

Qt Automotive Suite 2.0 Released

We are happy to announce the release of Qt Automotive Suite 2.0, the Qt solution for digital cockpits, developed in collaboration between KDAB, The Qt Company and Luxoft.

The Qt Automotive Suite provides OEMs and Tier1s with powerful frameworks and tools to build a consistent user experience for both the instrument cluster and the center stack. Being built on top of an open platform, the Qt Automotive Suite makes it possible for the automakers to stay in complete control of the user’s brand experience.

The Qt Automotive suite seamlessly integrates KDAB's runtime introspection tool GammaRay in Qt Creator and with embedded device support of Qt for Device Creation. See the release blogs for GammaRay 2.8 and GammaRay 2.9 for a summary of the new features and improvements.

GammaRay texture inspector

Another focus area for KDAB has been a revamp of the Qt IVI module, providing a flexible framework to design create APIs to platform middleware. Using an IDL and code-generation as well as ready-made simulation backends enable work from day before the full hardware or software stack is available. Having tooling support built in makes your APIs runtime instrospectable out of the box, for easy debugging or automated testing. For more details, see KDAB engineer Mike Krus' presentation about the Qt IVI changes.

There are many more improvements in Qt Automotive Suite 2.0, make sure to check out the release blog.

See Qt Automotive Suite 2.0 in action, visit KDAB at the Qt stand in Hall 4-258 at Embedded World 2018. continue reading

The post Qt Automotive Suite 2.0 Released appeared first on KDAB.

Introducing Qt Automotive Suite 2.0

We are excited to announce the Qt Automotive Suite 2.0, a great leap forward towards a unified HMI toolchain and framework for digital cockpit, available end of February 2018.

A few years back, we saw several challenges in the industry. One was that with increasing number of screens being present in the car, creating and maintaining a consistent digital UX across multiple displays with strong brand differentiation is unquestionably difficult. Why? Because a perfectly integrated digital UX for the digital cockpit does not end with the UI/UX design, it is only the beginning. When an OEM sends out the design specification, the supplier typically utilizes different software tools and technologies for developing the instrument cluster and center stack (aka. IVI or Infotainment) respectively. Somewhere down the line, there will be unavoidable HMI refinement needed to ensure the digital UX on different screens cooperate in a cohesive way.

Another challenge was that there was little reusability from one project to another, from one customer to another. The re-usability issue was particularly prominent on the center stack development. There was a lot of duplication of work when creating a new center stack HMI and it was just inefficient. Low re-usability made it difficult for the industry to rapidly innovate and differentiate on the HMI, and the development cycle was long and costly.

The third challenge we saw was that the center stack HMI has been traditionally monolithic, meaning all features (e.g. HVAC control, media player, radios) are packed into a single software instance. This approach not only created risks of introducing bugs, but more importantly, each feature may interfere with each other. If one feature crashes, the whole center stack needs to restart. This creates a lot of headache for developing and maintaining the HMI development – it is difficult to split the features into smaller sub projects for parallel development, and a pain to maintain a monolithic code base. Of course, if one feature needs update, the whole center stack needs to be rebuilt and reinstalled.

We solved these challenges, working with our strategic partners Luxoft and KDAB, announcing our first release of the Qt Automotive Suite 1.0 in 2016. We created the market’s first unified HMI toolchain and framework for digital cockpit development.

Today, we are happy to report that Qt Automotive Suite has been well received and are being adopted by some of the major OEMs in the world. An increasing number of customers are switching from the traditional specification writing and outsourcing, to owning the HMI design and development. We are glad to see the market is transitioning toward this direction that matches well with our vision, and the Qt Automotive Suite proves to be the right solution. Above all, we are seeing millions of cars shipped with Qt Automotive Suite in the coming years.

So, what is in Qt Automotive Suite 2.0?
Let’s look at the diagram.


Figure 1: Qt Automotive Suite 2.0

Qt Automotive Suite 2.0 builds out a vision to provide easy-to-use tools that free designers and software engineers to rapidly create superior digital cockpits. Before we jump in to the key features, here is one digital cockpit reference that is built with Qt Automotive Suite.

Qt for Device Creation

As customers are adopting Qt Automotive Suite for production development, the feature set and stability must be carefully balanced. Now the Qt Automotive Suite 2.0 sits on top of Qt 5.9, bringing major performance improvement and feature set while receiving Long Term Support (LTS).

Qt 3D Studio 

We believe a truly unified HMI toolchain and framework should also ship with advanced UI authoring tool for the designers. With 3D becoming a more significant part of the HMI we saw the need for a design tool that facilitates rapid 3D UI/UX concepting and design. For that, we now included the Qt 3D Studio into the suite.

Qt Safe Renderer

Functional safety is a critical path that our customers must cross. Qt Automotive Suite 2.0 includes the Qt Safe Renderer, ensuring the rendering of safety critical telltales is reliable and certifiable by ISO 26262 part 6 ASIL-B specification.

Qt Application Manager

Qt Application Manager brings a modern multi-process GUI architecture to the IVI. By separating the HMI into different functional units (for example, HVAC could be one unit while Navigation could be another), Qt Application Manager enables independent teams to develop and test both separately and simultaneously, thereby reducing project risk and shortening development time. In addition, splitting the UI into smaller applications also makes it easier to do system updates; smaller pieces of code are touched, and the OTA updates are smaller.

Qt Application Manager is a headless, core component. Despite the application management tasks, Qt Application Manager powers the Reference UI which implements a system UI compositor and the home screen along with a selection of apps.

In Qt Automotive Suite 2.0, the user can now make a custom application executable based on Qt Application Manager internal libraries. This greatly improves flexibility and makes integration in customer specific system setups easier. The new and extended system monitoring APIs has been extended and now also allow monitoring of resources consumed by separate applications. During the startup, the new logs allow tracing and profiling of apps in much larger details. Another improvement to mention is further polishing of the single-process mode, which allows running QML-runtime application on single process setups in the same way as on multi-process ones.

There are lots of other improvements under the hood, be sure to check out the latest documentation.

Qt Application Manager Plugin for Qt Creator

Since Qt Application Manager controls the application life cycle, direct launching from Qt Creator is now possible. A special plugin is provided now which wraps the command line tools provided in Qt Application Manager and integrates all essential steps into Qt Creator IDE. In Qt Automotive Suite 2.0, the plug-in uses the Generic Linux device type as a base. In the future it will directly use Boot2Qt device types to unify the device setup.


To tackle reusability, QtIVI brings a level of standardization within the Qt ecosystem for how to access and extend automotive-specific APIs. The applications developed in one generation of program can be reused on the next, even if the underlying platform is different. This is particularly important as OEMs are increasingly taking control of the car HMI development. Reducing duplication of work means significant cost saving and more focus on branded UX differentiation. Qt Automotive Suite 2.0 will integrate well with industry’s leading initiatives such as GENIVI and AGL, further increasing the re-usability on the platform level for the entire industry.

At its core, Qt IVI is built around a pattern based on the separation of API facing the application developer, so-called Feature, and the code implementing it, the Backend. There can be multiple backends per feature and the Core module provides support for finding the corresponding backend in an easy-to-use way.

Common use cases driving this separation are:

  • Early development, where the UI can rely on a feature with a very basic backend implementation.
  • Testing / simulation, where the backends can be tested separately from the app and the app can be tested using a specialized testing backend.
  • Targets with different hardware configurations, where certain parts of the system are represented by simulated backends while others use a real hardware integration.
  • Dynamically appearing services, when services are available sometimes, but not always, meaning that backends come and go over time.

The module provides an extendable set of reference APIs for automotive features. It can be used to develop automotive applications and to provide automotive features to Qt-based applications in a structured manner.

We added a way to describe interfaces using an IDL (interface definition language) and then generate Qt/QML API code based on this definition. We use QFace IDL and its libraries, which provide a generic auto-generation framework. In addition to the generic integration of a QFace-based auto-generation into QtIVI Core, we migrated the Climate and Vehicle Settings APIs to be based on IDL.

From the interface definition, the tooling generates the QML and C++ APIs, code that allows properties (i.e. values) to be inspected and overridden by other tools such as GammaRay and Squish, and the code for a simulator that will allow a developer to observe and control vehicle data values in the absence of a real vehicle to test on. This is useful not only for debugging but also for automated testing.


Figure 2: Qt IVI auto generator architecture

The grey boxes are the only parts what the customer needs to implement. The visible part (to the end user) is the application that uses the vehicle data. The non-visible part is the communication with the vehicle data service which is typically an independent process that communicates via an IPC.


The Qt Automotive Suite deeply integrates GammaRay into the QtCreator which allows for runtime introspection, visualization and manipulation of internal structures such as scene graphs and state machines. This can provide an insight into the running system to diagnose those hard problems and understand where memory is being used.

In Automotive Suite 2.0, our partner KDAB has added new texture inspection capabilities, improved Qt Quick layout diagnostics, support for QML binding analysis, and many other improvements. In addition, GammaRay’s performance has been improved to reduce the analysis impact on the target application and increases the responsiveness of the remote views. Make sure you have a read on GammaRay.


Figure 3: GammaRay can identify resource waste and even suggest remedy

Reference UI: Neptune

Since the initial release of Qt Automotive Suite, Qt Quick Controls 2.0 were released providing significant improvements in performance and more flexible styling. The Neptune reference UI has been upgraded to use Qt Quick Controls 2.0. The UI initialization supports staged loading for better performance. There is a new Notification framework with a Notification Center, Application Expose allowing to stop apps. Check out the documentation.

After 2.0, we will provide a new UX design and implementation developed by our partner Luxoft. Some of you might have seen it already at the CES or at the Embedded World shows this year.


Figure 4: New Neptune UI

The future System UI highlights Qt’s unique windows compositing capabilities. Take a look at the Phone, Maps, Player app widgets, they are run as separate apps and composited together on one screen managed by the System UI that acts as Application Launcher and HVAC control.

Comprehensive Documentation

Qt Automotive Suite 2.0 is now more mature, and one aspect is that we now have much better documentation for all the existing and new tools, components, and APIs.

SDK Creation

Let us reiterate this. Many times, parts of the system functionality will be delivered by second and third parties. Or third parties may want to develop apps specifically for your platform. The Qt Automotive Suite makes it easy to build a redistributable SDK that contains your specific HMI assets and added middleware together with the Qt tooling to allow 3rd parties to build and test their apps with minimal intervention.

Open Development Model

The Qt Automotive Suite will be developed in the same open manner as Qt itself. The code is available at http://code.qt.io/cgit/ and there is an automotive specific mailing list (http://lists.qt-project.org/mailman/listinfo/automotive) for discussions on engineering and product direction.


With Qt Automotive Suite 2.0, we now provide a truly end-to-end solution for the digital cockpit HMI development, bringing designers and developers to work under the Qt ecosystem, maximizing consistent digital UX for all screens while equipped with Functional Safety. With reduced design-development roundtrip and underlying cost, OEMs can now focus more on HMI innovation and brand differentiation, which is a win for the whole industry and consumers like you and us.

The post Introducing Qt Automotive Suite 2.0 appeared first on Qt Blog.

Qt Visual Studio Tools 2.2.0 Released

We have released the Qt VS Tools version 2.2.0.
Important changes include:

For details of what is included in this version, please refer to the change log.

The installation package is available in the Visual Studio Marketplace and can be installed directly from within VS (through the ‘Tools > Extensions and Updates…’ menu). Alternatively, it can be downloaded from this page.

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

Qt Internationalization – Create Your UI Using Non-Latin Characters

People, ideas and data are moving all around the world nowadays, and so are your applications! Developing a UI in one language only, regardless of the platform is not an option anymore. Now if you are lucky enough to be using Qt, this is achievable with little effort, even when dealing with non-latin characters and “right to left” languages.

This tutorial will guide you towards this goal with your Qt Quick application and will hopefully give you some, useful tips!

Phase 1: Translation Files and Iupdate

1.1 Generate Your Translation File in Qt

The first thing to do is to translate your application. It means you have to take all the static strings in your application and replace them with the translated version at the right time.

In Qt, this is first done by declaring translations files and using translation methods (tr, qsTr, QT_TR_NOOP). Your application will require exactly one translation file per supported language.

This is how you have to modify your project file and QML files to enable extraction the strings to translate:


    translations/en-US.ts \
    translations/zh-CN.ts \
    translations/ar-MA.ts \

lupdate_only {
    SOURCES += \

Windows {
    width: 800; height: 480
    title: qsTr ("My Application Title")

If you are wondering about the “en-US” notation, it corresponds to IETF language tags (https://en.wikipedia.org/wiki/IETF_language_tag). It is the juxtaposition of the language and country code and is often used to identify languages and locale.

Also, note we used ‘lupdate_only’ conditional in order to add our QML files to SOURCES only for the lupdate step. The SOURCES variables are used to compile your .cpp files, but they also happen to be used by lupdate to extract the translations.

At this point you can manually generate the translation files in QtCreator using “Tools > External > Linguist > Update translations (linguist)”. This will regenerate .ts files after parsing all files from the SOURCE variable of your project. You will end up with three .ts files (XML format) in your project, containing your new untranslated string “My Application Title”, its context (i.e. file) and its line number.

1.2 Now Apply Your Translation

You can then apply a translation.

Instantiate a QTranslator class, and use the QCoreApplication::installTranslator() method.

QTranslator *arabicTranslator = new QTranslator (":/translation/ar-MA.ts");
qApp ->installTranslator (arabicTranslator);

More than one translator can be installed at the same time. Qt will translate your strings using the last applied translator, and sequentially the next ones until it succeeds… or not. If not your original string will be displayed as it is written in your code.

Window {
    width: 800; height: 480
    title: qsTr ("My Application Title")

Phase 2: Translation at Runtime

Another common request is to dynamically retranslate the user interface. Changing the translator at runtime is quite simple, but updating the strings to reflect that modification may be a bit more challenging.

Fortunately, Qt provides QEvent::LanguageChange event for that purpose.

It is generated when you apply a new translator. This is what you will use for Widget based applications, along with the retranslateUi method for Designer generated UIs.

However, this is not very convenient and I found there is another simple solution.

  • Expose an empty QString property, trTrigger in our case
  • Bind your texts with this property like ‘text:qsTr(“My text”) + app.trTrigger
  • Emit trTrigger “changed”signal every time the language changes

You will get the full expression being re-evaluated (hence retranslated) while keeping the text unaffected.

Window {
     width: 800; height: 480
     title: qsTr ("My Application Title") + app.trTrigger

Phase 3: Supporting Chinese, Arabic, and Others

This is where font and text encoding become important. You may already have stumbled upon related issues when copy-pasting special characters from another document, only to discover they were replaced by unreadable ones. The two usual suspects are the Font and the Encoding of your document.

  • An incorrect encoding won’t be able to store or translate the characters correctly
  • An incorrect font won’t be able to render the characters

For example, Ask Comic sans MS to tell you “你好!”, and it will just fail. If this happens (and it probably will), it simply means your system or software uses a different or fallback font. This fallback font is used to render Chinese, despite the fact the original font does not support Chinese characters. And this is exactly what Qt will do when possible, saving you some work!

That’s why for the best visual outcome you will need to include fonts that are compatible with the language you want to support. If you then package these fontswith your application, you can easily install them dynamically using the QFontDatabase, or FontLoader on QML side.

On Linux platform, just make sure you have a fontloader library installed and available otherwise it won’t work. The encoding is less explicit than the font. It applies to files and variables storing your text. As long as you stick with QString for display and Qt translation mechanism you should be fine. But when you manipulate non-ascii characters you will have to take a few precautions:

  1. In files, make sure that encoding supports the characters you use (UTF-8 is a good default choice)
  2. In variables, make sure that it supports such characters (e.g. std::wstring vs std::string).

As for classic Qt translation, you will have to provide the corresponding .ts file to the person in charge of translations (e.g. “translations/zh-CN.ts”), as well as the linguist application from your Qt folder (e.g. “C:\Qt\5.8\mingw53_32\bin”).

Yes, I used a Windows path as an example, because I doubt that people working on your translations will be able to run linguist from your custom Linux distribution Linguist is a standalone application, so translators won’t need to install Qt, don’t worry.

This standalone application allows loading and saving .ts files, once the translations are done.

Witekio Qt Linguist Chinese

Now ask your translator to send you the .ts file modified: you’re done!

Phase 4: Don’t Forget that Right to Left Is Not Only a Text Thing

User interface composing is where the biggest difference compared to Left-to-Right languages lies.

In Arabic and Hebrew, you read and write from the right side to the left, and this has a significant impact not only on the text but on your whole application including:

  • Text alignment (right aligned by default!)
  • Menus and components position
  • Writing direction
  • Lists direction

In a way, this is like flipping your entire UI layout horizontally. Qt will locally help you change text alignment based on the character set used, but you will have to anticipate and implement the global strategy.

At the application level, you have the “setLayoutDirection” method. It is typically set from the application language, but you can also do it manually with:

qApp->setLayoutDirection (Qt::RightToLeft);

Qt Quick application then provides different ways to deal with layout direction. QML Layouts have the layoutDirection property, Images have the mirror, and all Items have the very powerful LayoutMirroring attached property.

”LayoutMirroring” is a fast way to change the direction of layouts, positioners (Row, Grid, …), anchors and text alignments, of the item and its children with only two lines:

Page {
     LayoutMirroring.enabled: (Qt.application.layoutDirection === Qt.RightToLeft)
     LayoutMirroring.childrenInherit: true
     Row {
         // Row will use right-to-left order when LayoutMirror.enabled = true
         Text {
              id: songNumber
              text: "1."
              horizontalAlignment: Text.AlignLeft // Alignment will adjust too. But don't fail to mention it         
                                                  // or the text won't change its alignment
         Text {
              id: artistItem
              text: "Some Artist"
              horizontalAlignment: Text.AlignLeft
              // Manually change elide side
              elide: (Qt.application.layoutDirection === Qt.LeftToRight) ? 
Text.ElideRight : Text.ElideLeft

LayoutMirroring.childrenInherit will apply the mirroring to all the children, making it a very efficient way to apply it. However be careful as it will very likely break some parts of your UI if you have not built it from the beginning with “Right-to-Left” and “Left-to-Right” in mind.

The example below shows the difference between standard English version and Arabic right-to-left version. Note that not only the text alignment is changed, but also the layout and the “+” and “-” buttons. This may look odd to some of you, but remember that right-to-left languages are not only about the text, but also the way eyes scan the content of the application.

Witekio | qt-application-english et qt-application-arabic-rtl


How Can You Make Chinese, Arabic, and Left-To-Right Integration as Easy as Possible? Wrap Up!

  • Use Qt Linguist and QTranslators for translations
  • Pack the fonts you want to use in your application for Chinese, Arabic, etc and install them with QFontDatabase or Fontloader
  • Do not use absolute positioning (the default “x:O” does count as such!)
  • Do use Layouts and positioners
  • Do use anchors and anchors margins
  • Do set Text.horizontal Alignment property

Qt provides you with a good start for integrating a lot of languages. With a bit of work and anticipation, your application will be understood all over the world. The key to an efficient integration of Right to Left languages is simply to plan and test it early during application development, to ensure it is fully compatible.

On embedded devices, don’t forget that Chinese, Russian and Arabic, only to name a few, need more than a simple keyboard layout, but also a way to “compose” different words based on what was typed. This is critical if you created your own virtual keyboard.

People will not be able to write in these languages simply with a different keyboard layout. Hopefully, the Qt Virtual Keyboard (Commercial or LGPLv3 license) does provide such specific input method, if you are not willing to redevelop it for yourself.

Another way is to use a carefully selected iconography. Symbols may not have exactly the same meaning in all countries, but if carefully picked up, they can help you keep your UI simple and clear.

And guess what? Resources (like images), paths and names can be translated too!

website: www.witekio.com  –  blog: www.witek.io

The post Qt Internationalization – Create Your UI Using Non-Latin Characters appeared first on Qt Blog.

The Qt Project and Google Summer of Code 2018

This year, for the first time, the Qt Project will be participating in the Google Summer of Code initiative.
This is an awesome opportunity for students who are interested in or are already involved with Qt development, and who want to flip bits and not burgers during their summer break!
What this means in practice is that by submitting a strong project proposal to the initiative, you as a student have a good chance to get a nicely paid summer job working on new features or improvements to Qt!

How to participate

For students, the recommended approach to participate in this initiative with the Qt Project is to start off by reading up how the whole thing works. Then, come up with a project idea (or choose one of the suggested ideas in the Qt Project’s wiki page), and reach out to mentors as soon as possible in our dedicated channels (in #qt-gsoc IRC channel on the Freenode network, or through the development mailing list).

In these channels you can discuss your idea with mentors (and the community), then get started, with the help of the mentors, to write down your project proposal and finally submitting it. The deadline for the submission of your proposal is the 27th of March.

Hope this sounds like an interesting opportunity and we hope that you will participate in making Qt even better!

The post The Qt Project and Google Summer of Code 2018 appeared first on Qt Blog.

Qt Roadmap for 2018

Qt 5.9 LTS is a solid baseline, which continues to improve still during 2018. Qt 5.10 was released in December, but there is more cooking. We are currently finalizing the Qt 5.11 release for May and looking towards Qt 5.12 LTS in November. In addition to the Qt framework we are actively developing our tooling offering. Tune in for an overview what we have in the works for 2018.

This blog post is a continuation of roadmap posts I have written for 2016 and 2017. As always, there is more to tell than what reasonably fits in a blog post, but I will try to talk about the most interesting items. There will be many more blog posts, videos, webinars and of course product releases throughout 2018 to provide details of the numerous items we are developing. Just like in the earlier posts, I would like to thank each and every Qt developer for their contributions. Most of the functionality is created by The Qt Company, but we also have a great ecosystem with many contributors. They have provided multiple extremely valuable contributions throughout the years and continue to shape Qt also in the future. In addition to those contributing code, we have also a large number of people active in the Qt Project forums, on mailing lists, as well as reviewing code and testing the Qt development releases. Together we create Qt!

Timelines for Qt 5.11, Qt 5.12 LTS, a lot of great tools and more

For 2018 we are planning to have two Qt feature releases: Qt 5.11 in May and Qt 5.12 LTS (Long Term Support) in November. As usual, we offer pre-releases for testing the new features. We will also create patch releases for these to address issues reported by users. In addition, we continue to make Qt 5.9 LTS patch releases throughout 2018.

For Qt Creator we are planning to have three feature releases: Creator 4.6 in March, Creator 4.7 in July and Creator 4.8 in November, providing incremental improvements and new functionality for our awesome IDE. The latest addition to our tooling offering, Qt 3D Studio, is planned to release a major new version in June: Qt 3D Studio 2.0 with new runtime based on Qt 3D. During the second half of 2018, we are planning to release Qt 3D Studio 2.1 in September and Qt 3D Studio 2.2 in December.

For our industry offering we continue to develop Qt for Automation and Qt Automotive Suite further. A major new version, Qt Automotive Suite 2.0, is planned to be released soon, followed by incremental update releases. We are also introducing new Qt Safe Renderer 1.0 for use in safety critical applications of Qt.

So, a busy year ahead of us. Now, let’s dive a bit into the features and functionality included in these releases.

What is coming with Qt 5.11 and Qt 5.12 LTS

Qt 5.9 LTS has been a solid baseline with multiple patch releases providing bug fixes and other improvements. We have already fixed over one thousand user reported issues with the Qt 5.9.x patch releases and intent to continue these during 2018. Qt 5.9 LTS has recently entered the Strict phase, which means we will fix the most important bugs, but the less important fixes will be targeted to Qt 5.11 (and later 5.12 LTS). In addition to continuously improving the quality, we are actively focusing into performance of the key use cases. We are constantly measuring performance in order to identify commits that have caused a performance regression in some area – and we also improve performance whenever possible. With the focus in both fixing bugs and improving performance, new Qt releases run the existing applications faster and more reliably.

When it comes to new features, we have many things ongoing related to graphics, so I’ll start with that. One of the biggest things for 2018 is the unification of our 3D engines. Qt 3D Studio 1.x releases use the 3D engine contributed by NVIDIA. While it is a good and solid engine, the benefits for migrating on top of Qt 3D are clear: easier to use both pre-defined and programmatically created content in the same application, improved support for different operating systems and hardware, and of course also avoiding the need to develop and maintain two different 3D engines.

Activities for being able to run Qt 3D Studio applications on top of Qt 3D have been ongoing for a long time and there are quite many improvements also to Qt 3D itself done during the process. Some of these are the improvements done to Qt 3D performance and reducing memory consumption of Qt 3D needed to efficiently run complex Qt 3D Studio applications on top of it. A great example of the benefits of unification is that these performance improvements to Qt 3D benefit also the existing Qt 3D applications – in addition to the upcoming Qt 3D Studio 2.0 applications.

Another major item for graphics is asset conditioning, essential for being able to reach optimal performance on target hardware. Both for 2D and 3D graphics, the size of assets is often a significant part of the overall application size and especially runtime memory footprint. During 2018 we continue to improve the asset conditioning support in Qt by adding more supported texture compression and packaging formats and making it easier to handle the graphical assets in build system and tooling.

Basic support for ETC1, ETC2 and ETC2_EAC compression was added already with Qt 5.10. Qt 5.11 improves the texture compression implementation and adds support for the commonly used KTX (Khronos Texture) texture file format. Modern GPUs with OpenGL ES 3.x support can handle the compressed textures efficiently, leading into improved memory usage and performance with the new Qt versions. We aim to continuously improve the asset conditioning capabilities of Qt and are currently looking into texture atlassing and other possibilities in order to further improve the performance and memory usage of textures.

Other areas we are working within the graphics are improved support for Vulkan and introduction of initial Metal support with Qt 5.12. We have also been looking into support for hardware graphics layers especially when using Qt Wayland. This is still quite hardware specific, but we have already enabled it with some commonly used SoCs.

Completely renewed gesture handling a.k.a. Pointer Handlers as a new approach for mouse, touch and gesture event handling is a major area we have been working on for quite some time now. The main issue addressed with the new functionality is versatility especially in multi-touch and multi-monitor applications, which is an area where the previous functionality has not been enough to tackle all aspects. The new functionality enables implementing other kinds of control mechanisms in Qt applications, for example based on hand gestures detected by a camera or a proximity sensor.

Pointer Handlers provide lightweight declarative API for recognizing and handling the most common mouse, touch and multi-touch gestures (press-hold-release, drag, swipe, and pinch) from mouse and touchscreen, in parallel across the scene. You can interact with multiple Items simultaneously, across multiple screens when necessary. First introduced as a Qt Labs feature, this is planned to graduate to a fully supported feature with Qt 5.12. Pointer Handlers can be extended to handle more use cases and are intended to have a public C++ API in upcoming releases.

Qt Quick Controls 2 received the initial capability for image-based styles with Qt 5.10. We are looking forward to completing the offering in Qt 5.11 and new design templates, including a template for Inkscape (in addition to Sketch, Illustrator and Photoshop templates). We are also well in progress for a new, performance optimized, table view implementation for Qt Quick, aiming to land in Qt 5.12. The target is to offer the new table view as a patch to be tested on top of Qt 5.11 in order to get early feedback. The implementation is done from the ground up with performance in mind, and we believe it is now on a good level.

So, quite many new things for Qt Quick users, but not to worry – we have not forgotten users of Qt Widgets. On the contrary, already during the past year we have been increasingly addressing open bugs of Qt Widgets and intend to continue doing so during 2018 and beyond. Both Widgets and Qt Quick have their strong points and they complement each other nicely as fully supported parts of the Qt offering.

Qt WebEngine, our HTML5 engine based on Chromium, will get an update to Chromium version 65 with Qt 5.11. For Qt 5.12 LTS we are looking into possibilities for decoupling Qt WebEngine from Qt release schedules to allow more frequent updates of Qt WebEngine. This is still under research, but there seem to be quite tangible benefits from carving out Qt WebEngine to a separate item. Current thinking it that as a separate item we should be able to release Qt WebEngine every three months, following nicely the schedule of Chromium releases every six weeks. For Qt 5.12 LTS users this would mean the possibility to get not only the security updates, but a full new Chromium version supported on top of the long-term-supported release of Qt.

A big new thing we aim to release during 2018 is Qt for Python, i.e. bindings to Python programming language. Initially started as PySide, the work has continued for quite some time already. After a lot of work, we are reaching the point of being able to offer a technology preview to be used on top of Qt 5.11. For those not familiar with what Qt for Python is, it offers a set of bindings to enable Python applications to leverage Qt functionality. For example, Qt is a great framework to create the user interface of a Python application. Python is a powerful programming language with a large and growing user base. According to Stack Overflow, Python is the fastest growing programming language. Based on their analysis, the amount of Python developers exceeded the amount of C++ developers in 2012 and is currently over three times larger. Tiobe index ranks C++ to be still more popular than Python, but also based on their study Python is on a growth trajectory. Our hope is that many of the Python developers will find Qt valuable to use in their applications.

To complete the list of Qt framework items, let’s talk a bit about our ongoing research of Qt for WebAssembly. We have earlier looked into Qt for Native Client and emscripten and the current work for WebAssembly continues along the same path. Since 2017 the four leading browsers (Chrome, Edge, Firefox, and WebKit / Safari) have agreed upon the use of WebAssembly, so it is reaching to be a stable platform to run Qt on. We will blog more about running Qt applications on WebAssembly later, for now you can take a look at the code and build instructions.

Improved and new tooling for Qt development

In the tooling area, we have been working hard to create the new Qt 3D Studio based on the NVIDIA contribution we received a year ago. Qt 3D Studio is a great tool for creating interactive 3D user interfaces and applications. The editor is a cross-platform Qt application running on Windows, Mac, and Linux. Qt 3D Studio is not a tool for designing 3D models, these can be imported from commonly used tools such as AutoDesk Maya, MODO by the Foundry and even Adobe Photoshop, to mention some examples. Qt 3D Studio comes with a large set of materials and other assets to complement the models imported from other tools. The big thing for 2018 is the Qt 3D Studio 2.0 release where we switch the runtime to be based on Qt 3D. This allows deeper integration with other Qt functionality, improved portability, reduced maintenance effort and many other benefits.

While many of our Qt 3D Studio examples are geared towards Automotive and Digital Cockpit use cases, it is by far not just a tool for Automotive. Need for 3D user interfaces exists in multiple other industries such and automation, medical, entertainment, home appliances and more. Qt 3D and Qt 3D Studio are also fit for the creation of AR and VR applications – a raising technology area that has many benefits both for consumer and business needs. Automotive is an important area for Qt and we continue to develop Qt 3D Studio according to the needs of it, but not as the only industry to cater for.

In Qt 3D Studio 2.0 as well as the 2.x releases later in 2018 we focus especially into interoperability with other parts of Qt, for example, seamless integration with Qt Quick as well as improved integration with Qt Creator IDE. One of the upcoming key improvements in the editor is completely rewritten timeline component, providing greatly improved ergonomics and workflow. With 2.0 we also aim to provide the final and fully supported Behavior API and Data Node API. We also continue to improve examples and documentation in order to make the creation of 3D user interfaces with Qt efficient, easy and fun.

In addition to tooling for 3D UI creation, we are looking into ways to improve our tooling for 2D UI creation. In many cases, Qt Quick is all that is needed for the UI as it allows efficient creation of dynamic and interactive user interfaces. One of the areas we aim to improve is better support for importing assets from commonly used design tools. This has been possible before, but we want to make it better and easier also for people who are not experts in software development. Other key improvement areas include the functionality, ergonomics, and usability of the tooling – again also for people other than developers. The third key area to improve is the possibility to easily see the outcome of design changes in the target application, even in the target device. Ease of deployment to target device has always been a strong point of Qt Creator, but there is still room to improve. We are planning to have the improved 2D UI design offering ready for the first release during the latter part of 2018 – and will certainly provide more information of this during the year.

For Qt Creator, we have many incremental improvements planned to be done in the upcoming releases during 2018. Some of the main areas we are looking into are leveraging Clang code model, Python support, support for upcoming Qt target platforms (e.g. Qt for WebAssemby) and improved CMake support. Using Clang provides us with code-assistant functionality for modern (and future) C++ language standards. With Qt for Python, it is essential to offer Python support in Qt Creator, to allow convenient development and debugging of Python applications.

In addition to the high-profile features listed above, we continue to improve all the important areas of Qt Creator. For example, debugger support, code editor features (complementary to clang/qml code models) and releasing (improvements to the installation process, pre-releases via the online installer). Continuously improving CMake support in Qt Creator is needed to keep the growing CMake-using customer base satisfied. We also continue the development of QBS and maintenance of qmake, keeping also these as viable options for Qt applications. Just like with Qt in general, we are also continuously looking into the performance of Qt Creator and doing performance improvements.

A completely new component coming in 2018 is Qt Safe Renderer 1.0, which allows the creation of safety critical user interfaces much easier than before. It consists of two key items: integration to Qt Creator for the creation of safety critical user interface, and the renderer component for rendering the safety critical user interface. We are in the final steps to receive functional safety certification for the Qt Safe Renderer, including both the safety critical tooling and runtime parts.

Automation, Automotive, and other industries

In addition to improving the generic product offering according to feedback from customers and focused industries, we also have some items developed especially for the needs of certain industries. These are available for any industry but expected to be most relevant for the one they are named after. Prime examples of these are Qt for Automation and Qt Automotive Suite.

To learn more about Qt for Automation, check the blog post introducing it. The main items we have been cooking for 2018 are fully supported MQTT, KNX and OPC/UA implementations. Qt Mqtt and Qt Knx technology preview have been available since last year and both will be fully supported with the upcoming releases of Qt. Qt OpcUa is a new item, which we aim to first provide as a technology preview with Qt 5.11 and then finalize it for use with Qt 5.12 based on the feedback.

Qt Automotive Suite, available since 2016 is reaching 2.0 version soon. Based on Qt 5.9 LTS, Qt Automotive Suite 2.0 is a combination of automotive specific functionality from The Qt Company and our partners KDAB and Luxoft. Version 2.0 bundles with the Qt Safe Renderer, Qt 3D Studio, and includes an overhaul of QtIVI with the ability to generate APIs from an QFace IDL, improvements and added features to the Neptune UI, Application Manager and the GammaRay runtime introspector.

Get involved

If you want to learn more about upcoming things for Qt, please stay tuned for new blog posts and webinars about the upcoming features, contact our sales teams or join the discussion in the Qt mailing lists and developer forums. We are always delighted to see new contributors in the Qt Project as well as feedback to the pre-releases of Qt via bugreports.


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

Release 2.15.1: New Firebase Features and New Live Code Reloading Apps | Upgrade to Qt 5.10.1 & Qt Creator 4.5.1

V-Play 2.15.1 adds support for Qt 5.10.1 and the latest Qt Creator 4.5.1. Qt 5.10.1 comes with over 300 fixes and improvements. Qt Creator 4.5.1 adds several fixes as well. This update also improves the V-Play Firebase components with easier configuration and callback functions.

V-Play 2.15.1 Improvements

V-Play is now compatible with Qt 5.10.1 and Qt Creator 4.5.1. See later parts of this post for the highlights. V-Play Release 2.15.1 also includes many engine improvements:

New Live Code Reloading Apps for Desktop, Android and iOS

V-Play 2.15.1 comes with an improved V-Play Live Client and Server. The updated Live Client supports all new features and components.


Reworked UI for Live Reloading Android and iOS Apps

There’s also a new V-Play Live version available for you on Android and iOS. The UI received a complete rework.


Project Cache to Open Recent Projects

It includes a new project cache, that lets you view your recent projects. This allows you to open your projects on your mobile phone also when not connected to your desktop, to show it to friends, customers or to yourself.


Run Code Examples from Documentation and Blog with the V-Play Web Editor

The new live client app also improves using the V-Play Web Editor. With the V-Play Web Editor, you can run code examples on your Android or iOS phone, right from your desktop browser. It’s a Cloud IDE for editing, running and debugging QML Code. Here is an example that you can try right away:

import VPlayApps 1.0
import VPlay 2.0
import QtQuick 2.8

App {
  NavigationStack {
    Page {
      title: "My First App"

      AppButton {
        anchors.centerIn: parent
        text: "Celebrate"
        onClicked: {
          nativeUtils.displayAlertDialog("Yay", "That is so cool!")

You can read more about this feature in this blog post.

Download the Latest Apps for Android and iOS

The new apps include all the latest V-Play features, so make sure to get the updated app to be fully compatible with current version of V-Play Engine and the Live Server. You can download the app for iOS and Android here:

Google_Play_Badge-1App Store
ic_launcherV-Play & QML Live Scripting App
Search in App Stores for: “V-Play Live Scripting”

Use WebView with Live Reloading on Android and iOS

The new V-Play Live Client mobile apps support the QtWebView module. You can now use code reloading also for apps that include a WebView.

import VPlayApps 1.0
import QtWebView 1.1

App {
  id: app

  NavigationStack {

    Page {
      id: page
      title: "WebView"

      WebView {
        anchors.fill: parent
        url: "https://www.google.com"

Note that the WebView module is not available on Windows desktop.

Test Firebase and Facebook Plugins with Live Reloading

With the new V-Play Live Client apps, you can test the Firebase and Facebook plugins, without any integration steps. Note that both plugins connect to public test accounts, so make sure not to store any sensitive data.

import VPlayApps 1.0
import VPlayPlugins 1.0

App {
  id: app

  NavigationStack {

    Page {
      id: page
      title: "Firebase Database"

      FirebaseDatabase {
        id: database
        onReadCompleted: {
          if(key == "teststring") button.text = value

      AppButton {
        id: button
        anchors.centerIn: parent
        text: "Read Value"
        onClicked: {
          // get value from database. the result is processed in onReadCompleted of FirebaseDatabase

Firebase Callback Functions

When reading and writing data to and from a FirebaseDatabase, you can now use callback functions in addition to the item’s signals FirebaseDatabase::readCompleted() and FirebaseDatabase::writeCompleted().

You can supply a function as third parameter to the methods FirebaseDatabase::getValue(), FirebaseDatabase::getUserValue(), FirebaseDatabase::setValue() and FirebaseDatabase::setUserValue(). Both the signal and the callback function will be called on completion.

This is the same example as above, using a callback function instead of the readCompleted signal:

import VPlayApps 1.0
import VPlayPlugins 1.0

App {
  id: app

  NavigationStack {

    Page {
      id: page
      title: "Firebase Database"

      FirebaseDatabase {
        id: database

      AppButton {
        id: button
        anchors.centerIn: parent
        text: "Read Value"
        onClicked: {
          // get value from database. the result is processed in callback function 
          database.getValue("public/teststring", {}, function(success, key, value) {
            button.text = value

Firebase Configuration from QML

It is now possible to specify your Firebase Plugin account configuration in QML code. You can override the default configuration of FirebaseDatabase and FirebaseAuth using the new type FirebaseConfig. This allows for using multiple Firebase accounts from within the same app. It also simplifies the Firebase configuration for you in general, because you do not need any google-services file, but can configure your Firebase app completely from QML instead.

import VPlayApps 1.0
import VPlayPlugins 1.0

App {
  id: app

  NavigationStack {

    Page {
      id: page
      title: "Firebase Database"

      FirebaseConfig {
        id: customConfig
        projectId: "v-play-live-client-test-db"
        databaseUrl: "https://v-play-live-client-test-db.firebaseio.com"
        apiKey: "AIzaSyCheT6ZNFI4mUwfrPRB098a08dVzlhZNME"
        applicationId: "1:40083798422:ios:ed7cffdd1548a7fa"

      FirebaseDatabase {
        id: database
        // assign custom config values. overrides config from google-services.json / GoogleService-info.plist
        config: customConfig

      AppButton {
        id: button
        anchors.centerIn: parent
        text: "Read Value"
        onClicked: {
          // get value from database. the result is processed in callback function 
          database.getValue("public/teststring", {}, function(success, key, value) {
            button.text = value

Native DatePicker Dialog for Android, iOS and Desktop

You can now let the user select a date from a native date picker dialog with the new function NativeUtils::displayDatePicker().


import VPlay 2.0
import VPlayApps 1.0
import QtQuick 2.9

App {
  id: app

  NavigationStack {

    Page {
      id: page
      title: "Date Picker"

      AppButton {
        id: button
        anchors.centerIn: parent
        text: "Display Date Picker"
        onClicked: {

      Connections {
        target: nativeUtils
        onDatePickerFinished: {
          if(accepted) button.text = date.toLocaleDateString()

Fix QML Import Issue in Qt Creator

After the last V-Play update with Qt Creator 4.5, some of you faced issues with import statements in QML. This did not affect building and running the application. Yet it caused error messages in Qt Creator and affected auto-completion and syntax highlighting.

With V-Play 2.15.1, this is now fixed.

More Improvements and Fixes

  • Improve rebound effect of list view in drawer used in Navigation (default on Android or if using navigationModeDrawer).
  • Improvements for VPlayMultiplayer matchmaking and error handling. Update to latest Photon version for multiplayer services.
  • Increased timeout between plugin trial notice dialogs.
  • Reduce duration of V-Play Splash screen during development for standard build & run from Qt Creator.
  • Documentation improvements in various components. (Special thanks to user Marcin for extensive contribution!)
  • Disable user location updates for AppMap if AppMap::showUserPosition and AppMap::enableUserPosition is false, to optimize battery usage on mobile devices.
  • Fixes an issue where games would be always started in fullscreen mode while developing, if previously an app was run in iOS theme.
  • Fix App::isOnline and GameWindow::isOnline property on macOS Sierra and iOS 10.
  • Fix user position and location circle for AppMap with MapBoxGL plugin.

For an overview of all changes, make sure to see the changelog here.

Qt 5.10.1 Improvements for App and Game Development

Bugfix Release

Qt 5.10.1 comes mainly as a bugfix release. It contains over 300 fixes and improvements, with close to 1400 changes over 5.10.0.

Fix iOS Font Rendering Issue

One major fix targets the font rendering issue on iOS. This issue caused texts with native font to appear in weird glyphs occasionally. With this update, fonts on iOS appear as beautiful as they are, all the time!

Qt Creator 4.5.1 Support

The new version fixes several issues and brings improvements to the Qt Creator UI. It fixes crashes when importing or switching projects, as well as the mouse cursor getting stuck in waiting state on Windows.

How to Update V-Play

Test out all 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 this release as described in the V-Play Update Guide.

V-Play Update in Maintenance Tool

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 this release!

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



More Posts Like This

Web Editor: Test Online Code Examples on Android and iOS with Live Code Reloading

Release 2.14.2: Live Code Reloading with Native Cross-Platform Plugins

Release 2.14.0: Live Code Reloading for Desktop, iOS & Android

The post Release 2.15.1: New Firebase Features and New Live Code Reloading Apps | Upgrade to Qt 5.10.1 & Qt Creator 4.5.1 appeared first on V-Play Engine.

emBO++, Bochum, Germany

KDAB is sponsoring this annual Embedded C++ conference and KDAB's Marc Mutz is speaking:
12-03 Midday, Views, views everywhere:

"There's a revolution coming.......`string_view` from C++17, `span` from the Guideline Support Library and `array_view` (targeted at C++2a) are just the beginning..."

Attend and find out more.

Check out KDAB Training for Modern C++ and much more.


KDAB is proud to be sponsoring emBO++, the only event in Europe dedicated to Embedded C++ users. continue reading

The post emBO++, Bochum, Germany appeared first on KDAB.

KDAB’s City Lights Display with Qt 3D


The City Lights demo is an example of Qt 3D being put to novel use to implement a deferred rendering pipeline.

With OpenGL, the number of lights you can show on a screen, also affecting objects in a scene, is limited by the need to use a forward renderer. Using Qt 3D, the geometry considerations can be separated out from the lighting ones, which massively reduces the complexity. This enables the scene in this demo to run on fairly mediocre hardware at 60 frames a second, even though it contains approximately 1500 real time lights.

KDAB Director, Dr Sean Harmer, maintainer of the Qt 3D project, explains.


  continue reading

The post KDAB’s City Lights Display with Qt 3D appeared first on KDAB.

Exporting 3D content for Qt 3D with Blender

At the heart of every 3D application is geometry. Qt 3D-based 3D applications are no different and require the user to either generate geometry or provide asset files for Qt 3D to load. This blog post demonstrates how Blender and its Python API could be used to write an exporter that generates geometry for Qt 3D.

For those of you not yet too familiar with Qt 3D, let me remind you that Qt 3D is based on an Entity Component System.
A given Entity gets its behavior defined by the various components it aggregates.

Assuming you want to render some 3D content, a renderable entity would be composed like so:

[sourcecode lang="cpp"]
Entity {
components: [
GeometryRenderer {
geometry: ...
Material {}


Loading Geometries with Qt 3D

There are currently 3 ways to incorporate geometry in a Qt 3D application:

Using the default meshes provided by Qt 3D Extras

QConeMesh, QCuboidMesh, QCylinderMesh, QPlaneMesh, QSphereMesh, QTorusMesh

These are all QGeometryRenderer subclasses which take care of generating geometry based on configurable properties. It's up to you to provide a Material that will shade your geometry.

[sourcecode lang="javascript"]
Entity {
components: [
ConeMesh {
rings: 16
slices: 16
topRadius: 0.1
bottomRadius: 1.0
Material {...}


Using QMesh component to load a geometry file

Several backend plugins are available for .obj, .fbx and gltf version 1. The list of plugins will likely grow in the future (work on a gltf version 2 importer is currently ongoing). QMesh is also a QGeometryRenderer subclass, you also need to provide a Material.

[code language="javascript"]
Entity {
components: [
Mesh {
source: "path/to/my/file.obj"
Material {...}


Using QSceneLoader component to load a scene file

QSceneLoader is also plugin based. At the time of writing, one such plugin is based on the Open Asset Importer Library (Assimp) which supports the following formats.

There's also another plugin which supports gltf version 1.

[code language="javascript"]
Entity {
components: [
SceneLoader {
source: "path/to/my/scene.obj"

The subtelty between QMesh and QSceneLoader is that QMesh loads only a single mesh whereas QSceneLoader will load an entire scene. Essentially QSceneLoader will generate a subtree of QEntity with QGeometryRenderer and QMaterial components. The nice thing is that QSceneLoader will also instantiate matching Materials to go with each mesh.

In most cases you'll either use QSceneLoader to load a rather complex scene or, if you know how the scene content is structured, decide yourself on which parts you need and use several QMesh components.


Now this is all fine but you'll often end up with one of these issues:

  • Geometry is generated at run-time which can be costly
  • Many 3D formats are text-based (takes up space on disk, slow parsing at run time)
  • Loading a scene subtree requires traversing said subtree to retrieve entities composed of components of interest
  • QSceneLoader may duplicate materials, effects, attributes depending on the scene file
  • Declaring several QEntity with QMesh components can be tedious
  • Import plugins for QMesh/QSceneLoader are not available on all platforms and may not cover all formats.


From a general perspective, the current mechanisms make it tedious for the developer to control a complex scene. They either completely hide away the structure of a loaded subtree or, on the contrary, force you to know exactly what composes your scene and let you do the heavy lifting of deciding which meshes you care about.

If you are after performance, you need to know how your scene is structured, which materials are in use and how large your geometries are. With this information you can decide if you need to:

  • rework you geometry to reduce the number of vertices to be drawn
  • group several parts together so that they can all be drawn at once
  • reduce the amount of materials required.

So what if instead of loading something blindly, we generated Qt 3D content in advance, as part of our tooling or asset conditioning work?



Blender is a free and opensource 3D creation suite. I wouldn't go as far as saying that it's intuitive to use for a newcomer, but it's a really powerful tool. In addition, it provides a powerful Python API which can be used to write importers, exporters or simply automate processes (importing and exporting geometries offline). The nice thing is that the API is documented, the bad thing is that the documentation is mostly a list of methods and members...

How could Blender solve any of the issues we have?

Instead of generating or loading geometry at runtime, I therefore decided I would try to experiment and write an exporter plugin for Blender.
The goal for it would be to generate the QML content for an application (though we could easily extend it to cover C++ as well) and export the geometry buffers to binary files that just need to be read at runtime without requiring any parsing.

This could solve the issues of slow startup caused by parsing text-based files and possibly duplicating effects and materials. This also solves the case of import plugins deployment (as we are now performing this offline) and only shipping binary files that can be read with the readBinaryFile functions on the QML Buffer element. Finally this also gives us the complete structure of our scene.

[sourcecode lang="javascript"]
Buffer {
type: Buffer.VertexBuffer
data: readBinaryFile("qrc:/assets/binaries/bufferdata.bin")


Creating a Blender Exporter Addon

A blender addon can be easily created by subclassing bpy.types.Operator and optionally bpy_extras.io_utils.ExporterHelper which provides convenience helpers as well as a default UI layout.

Overview of an exporter class

  1. Define members from bpy.types.Operator and ExporterHelper
    • bl_idname
      • The addon will be accessible in the Blender API though bpy.ops.bl_idname
    • bl_label
      • The name used on the export button UI
    • filename_ext
      • The name of our format extension if we have one
  2. Set UI properties and export options
    • Blender provides default property types
    • In the Qt3DExporter cases, properties were added to control:
      • whether to export only the selected objects or the whole scene
      • whether to export only the visible objects in the scene
      • whether we want meshes to be grouped in a collection
      • whether we want materials to be grouped in a collection
      • whether we want to export a full Qt3D application or just the
  3. Implement the draw method to lay out our properties
    • Retrieve the operator's layout and add rows and columns
      • We can add labels and reference properties you have previously created
  4. Define the execute method which will be the entry point of our exporter

[sourcecode lang="python"]
class Qt3DExporter(bpy.types.Operator, ExportHelper, OrientationHelper):
"""Qt3D Exporter"""
bl_idname = "export_scene.qt3d_exporter";
bl_label = "Qt3DExporter";
filename_ext = ""

# We set up exporter UI here
use_mesh_modifiers = BoolProperty(
name="Apply Modifiers",
description="Apply modifiers (preview resolution)",

use_selection_only = BoolProperty(
name="Selection Only",
description="Only export selected objects",

def draw(self, context):
layout = self.layout
col = layout.box().column(align=True)
col.label("Nodes", icon="OBJECT_DATA")
col.prop(self, "use_selection_only")
col.prop(self, "use_visible_only")

def execute(self, context):
# Actual exporting work to be done here

def createBlenderMenu(self, context):
self.layout.operator(Qt3DExporter.bl_idname, text="Qt3D (.qml)")

# Register against Blender
def register():

def unregister():


Most of the work will be done in the execute method. When reaching that point you'll want to:

  1. check which options have been selected by the user
  2. retrieve the export path selected
  3. gather data from the blender scene
  4. perform any post processing or conversion
  5. write the exporter data in whichever format you're interested


Parsing Blender Data


We can do a lot of things with the Blender API, the hard part is really finding out what you need

In our particular case we only care (for a first version) about:

  • Objects (bpy.data.objects)
    • Collections of objects that reference a datablock
      • name
      • data (reference to a datablock)
      • type (type of datablock being referenced)
      • matrix_local
      • matrix_world
      • select (whether we are selected or not)
      • parent (reference to a parent object)
  • Meshes (bpy.data.meshes)
    • Collection of datablocks containing information about a mesh
      • name
      • material slots (references to materials used by the mesh)
      • uv_layers
      • vertex_colors
      • vertices (list of position)
      • edges (an edge references 2 vertices)
      • loops (collection of loops, a loop references a vertex and an edge)
      • polygons (a list of loops forming a polygon)
  • Materials (bpy.data.materials)
    • Collection of datablocks containing information about a materials
      • name
      • ambient
      • diffuse_color
      • specular_color
  • Modifiers (object.modifiers)
    • Collection of modifiers an object can reference
    • A modifier is a visual transformation applied to a mesh
      • Mirror
      • Array
      • Solidify
      • Subsurface...
    • An object referencing a Mesh datablock that has modifiers can be transformed into a Mesh with the modifiers applied by calling object.to_mesh()
  • Lamps (bpy.data.lamps)
    • Collection of datablocks containing information about lamps
      • type (POINT, SPOT, SUN)
      • color
      • intensity
      • SPOT
        • spot_size (cut off angle)
        • constant_coefficient (constant attenuation)
        • linear attenuation
        • quadation attenuation
      • POINT
        • constant_coefficient (constant attenuation)
        • linear attenuation
        • quadation attenuation
  • Scene (bpy.context.scene)
    • References objects and render settings for the scene

Now that we know what we care about, the next part is traversing these collections and converting them to Qt 3D content.


First we need to go over all the meshes in the scene and gather information required to convert these to QGeometryRenderers, QGeometry, QAttributes and QBuffers.

The idea is to go over each Blender mesh and process then as follows:

  1. Triangulate
  2. Apply the modifiers it references
  3. Retrieve vertex data (position, normals, texture coordinates, colors)
    1. Write data into a binary file
    2. Record description of attributes
  4. Compute the indices
    1. For each material being referenced by the blender mesh
      1. Create a submesh (basically a QGeometryRenderer in Qt3D)
      2. For each polygon referenced by the submesh
        1. compute list of indices based on  the loops of the polygon
      3. generate and record the IndexAttribute for the submesh
    2. Generate the IndexBuffer based on the sub meshes
    3. Write data into a binary file.

We keep the data we have produced here for later.


Next, we need to gather information about each instance of Material of the scene to later on create and instantiate QMaterial subclasses.

For now the exporter is only recording the name, ambient, diffuse and specular color. Later on I'd like to extend that to either export a shader directly or switch to PBR materials.


Once we've created an intermediary representation for our mesh data and material data, we can proceed with the actual exporting of the scene.

The idea is to retrieve all the objects references by the BlenderScene. Then, from these objects, we can create a hierarchy.

Finally it's just a matter of traversing the tree.

For each object:

What type of object we are dealing with?


All of the above work has been implemented in a dedicated Exporter class. It is instantiated and called in the execute function of our addon which looks like below:

[sourcecode lang="python"]
def execute(self, context):
exportSettings = self.as_keywords()
exportSettings["global_matrix"] = axis_conversion(to_forward=self.axis_forward, to_up=self.axis_up).to_4x4()

self.binaryDirectoryName = "assets/binaries/"
self.shadersDirectoryName = "assets/shaders/"
self.qmlDirectoryName = "qml"

self.userpath = self.properties.filepath
if not os.path.isdir(self.userpath):
self.userpath = os.path.dirname(self.userpath)
msg = "Selecting directory: " + self.userpath
self.report({"INFO"}, msg)

# switch to work dir and create directories
if not os.path.exists(self.binaryDirectoryName):
if not os.path.exists(self.shadersDirectoryName):
if not os.path.exists(self.qmlDirectoryName):

# Save scene into scene
scene = bpy.context.scene

exporter = Exporter(scene, exportSettings)

# Create QML Files

# Create .qrc file

# Create main.cpp

# Create .pro


Does it work?

Well actually it does.

As a test sample I've used a mesh from blendswap

Where to get it?

Here. Usage instructions are provided on the repository. It should work with pretty much any blender scene. Just make sure you have assigned a material to the elements you want to export.

Next steps

  • Export Animations
  • Export Armatures
  • Better Material support
    • export textures
    • generate shader when possible
    • investigate if the QShaderProgramBuilder could be used to export node trees from blender
  • Use instancing for Array modifiers
  • C++ support

continue reading

The post Exporting 3D content for Qt 3D with Blender appeared first on KDAB.

Protecting a Qt Application or a Device Against Hacking, Part 2

by Sakari Himanen, Security Tech Lead at Intopalo Oy (Qt Blog)

Why would anyone want to hack an application or a device? And how would they go about their attack? And, most importantly, how can you protect your software against malicious attacks?

This post is a follow-up to part 1 of the topic. This time we take a fairly detailed look at attackers’ motivations, methods and the ways to deter most attacks from succeeding. This blog post is aimed primarily at anyone who have specific reverse engineering or tampering related risks in their systems, for example related to processing licenses, valuable content or media, proprietary algorithms or financial transactions.

Why would anyone want to hack my software?

“We’re not Facebook or handle ultra-sensitive data – why would anyone want to hack us?” It is easy to think that our application does not attract attackers to take the effort to reverse engineer the software.

However, there are several reasons why attackers might want to target any application. Here are the most common motivations.

Circumventing a licensing check

This is one of the most common targets. The attacker tries to disable the logic that checks for a valid license in order to be able to use the application without limitations. The usual way to achieve this is by modifying the application binary.

Extracting secret keys or passwords

Applications often contain embedded information which is used to encrypt the data stored in the application, enable protected communication for example with a cloud backend, or enable the application to use other resources that require authentication. By carefully analysing the application binary, it is easy to locate and extract the secret keys or passwords, if they are not protected.

Understanding how a proprietary algorithm works

Many applications contain implementations of algorithms that have intellectual property value. These may be developed by the company developing the application, or parts of the application that are licensed from other developers. If the algorithm code is not obfuscated in any way, the pseudo-code of the algorithm can be easily extracted from the application binary.

Finding open vulnerabilities that can be exploited to attack running systems

Many applications use third party modules (code, libraries, other assets) either directly or indirectly. Any such modules can have vulnerabilities. Further, updating such modules, especially in embedded applications, may not be straightforward. Obtaining knowledge of such vulnerabilities can be used to attack other systems that use the same modules.

Changing the application’s operation

Sometimes the attackers aim to change the behavior of the application, but only very slightly, so that the changed application is virtually not distinguishable from the original application. For example, consider an application used for financial transactions, used by consumers or businesses. If an attacker is able to distribute a slightly altered version that is able to manipulate a recipient’s bank account number, it is possible to gain significant monetary benefit in a short time before anyone notices the attack.

Changing the device operation or configuration

Physical devices depend more and more on the device software, such as firmware or special applications. Because of this, the configuration of devices is often done purely with software. For example, a high power variant of an engine may be just a locked configuration in the engine controller software. In this kind of scenario, the attacker aims to perform “feature unlock attack” by targeting to modify the controller software.

Making and distributing an application version that crashes or jams

Sometimes the attacker’s target is not to directly benefit from modifying the application. Instead, the target may be simply to cause harm to the services related to the application. For example, an application that crashes every time a certain operation is performed may cause significant monetary losses or bad reputation for the related services.

How attackers think – Popular hacking methods explained 

To protect your application against various kinds of attacks, it is useful to first think like an attacker. Try to think of the obvious ways to attack specifically against your application and the different motivations an attacker might have.

Even more importantly, think out of the box: what would be the unlikely but still possible attack against your application? Also, put yourself in different user roles and try to identify the ways to attack from the viewpoint of each responsibility actor of your application. The actors typically operate over trust boundaries and that may then reveal execution paths or data flow which initially do not seem likely or possible.

Static binary analysis

Probably the most common way to attack an application is static binary analysis. It is often easy to obtain the actual binary. Tools to analyse the binary are available either free or with a reasonable cost. Tools allow parsing and extracting the various parts of the binary with a single click. There is no need for the attacker to write custom code for every target platform or architecture.

A typical application binary contains multiple types of sections. They can be roughly categorized as sections containing code, sections containing static data such as strings and sections containing runtime data. Out of these, the code and static data sections are the most interesting for the static analysis context.

Static data sections, such as a string section, usually contain the data that can be considered as application assets. It is deceptively easy to think that data embedded as strings is protected from attackers. That is not the case. In the worst case, the string data may contain even passwords or application’s secrets in plain format. If they are un-encrypted or un-obfuscated, extracting the string values is as easy as reading a book.

The code section contains all of the application logic. Disassembler tools can easily resolve the pseudo code structure, call hierarchy, local and global variable references and other similar information. But even an average-sized application will contain lots of binary code. So, the aim of the attacker is not to resolve every line of code. Instead, the aim is to identify the relevant parts of code to be used as the target for the attack.

For example, a few hundred instructions containing a license check logic is an attractive target for an attack. It does not require very special knowledge to break the license check. At the very minimum, modifying one single instruction may be enough.



Capture from Hopper disassembler tool demonstrating the control flow capabilities

Dynamic binary analysis

If an application is using the typical first level of protection, the code obfuscation, static binary analysis may not be enough to reveal the secrets. The typical next step is dynamic binary analysis. This means basically analysing the application operation in runtime: collecting all the possible data from code execution and memory usage and analysing the execution paths that can’t be revealed with static analysis.

There is a wide range of tools available for dynamic analysis. The free or low-cost tools provide the basic capability for disassembling and debugging an application. But there are also high-end tools, such as IDA Pro, which are built with loads of tools for analysing the target binaries.

A crucial element of dynamic binary analysis is to also understand the attack context. The typical attack context is so-called “whitebox attack context”. It means that the attacker has full access to the target application, to the application binary and to the execution environment. In practice this means that the attacker is able to control every aspect of application execution when trying to break it or steal its secrets.

Why is the attack context so important? Because it drives the assumptions what the developer can do about possible attacks and how they affect your application. Once again, it is easy to assume that “as my application is running in environment X, attack type Y is not applicable”. But very often, usually due to the resourcefulness of the attacker, the attack context ends up being the whitebox attack which means that the assumptions done in the design phase are the ones which eventually leave the application vulnerable. For example, developer may think that if an application is running in an embedded device, an attacker has no meaningful access to it. But in reality, attacker could gain access to device firmware, remove the software protection in the firmware, and then attack the application directly.

Another important concept is so-called “code lifting”. Code lifting refers to the scenario where the target application can be lifted for example to a simulator environment where the attacker has full capability to control the code execution or monitor the memory usage – even kernel memory. This is often paired with the white-box attack context. First the attacker gain access to the target application binary, and then moves it to another execution environment.

Methods to protect applications and devices against hacking

In the first blog post, we presented some basic methods for protection of your application, such as using static linking instead of dynamic linking, and making sure that the symbol stripping is enabled when generating the final application binary. But when there is a need for more comprehensive protection, there are additional methods for protecting applications against various kinds of attacks.

These methods can be roughly divided to four categories:

  • Obfuscation
  • Anti-tampering
  • Anti-debugging
  • Whitebox cryptography


The purpose of code obfuscation is to mainly prevent static analysis. Typical ways to perform code obfuscation is adding obfuscation of the strings used in the application, encrypting the static data sections of the binary so that they are decrypted when the application starts, and adding artificial code structures or execution paths which cannot be resolved with static analysis.

An example of code obfuscation would be a case where a code block is paired with a parallel “copy block” and the execution of the two blocks is controlled with a conditional branch with specific characteristics. The branch logic should be deterministic so that the developer can trust that the code is executed correctly, but static analysis can’t deduce the runtime behavior.

Just like static analysis is the first way to perform an attack, it is also the first level of defense. For example, a high-quality disassembler may be able to see partially through the obfuscation patterns. Also, the quality of modern compilers poses a problem. Fake code blocks may be wiped away by code optimization and hence decrease the quality of obfuscation.


The purpose of anti-tampering is to protect the application against dynamic analysis. While there are various approaches on how to implement anti-tampering, the basic idea is that the original application binary is modified to include additional code that does runtime checking of the binary. Such code snippets monitor specific areas of the binary to check if the area is modified and perform counteraction if a modification is detected.

Applying anti-tampering is very much application and execution environment specific. For example, there is a tradeoff between how much code modification checks can be used vs. the performance of the application. Also, the target architecture plays a major role: an approach that works well in certain environment may not protect the application in a different environment.

This also means that adding anti-tamper protection is much more tedious that adding basic code obfuscation. While code obfuscation can be usually applied at the compiler frontend level, anti-tampering has a dependency to compiler backend and architecture-specific parts.


The purpose of anti-debugging is simply trying to prevent the attacker from performing code lifting and running the application in a simulator or a similar environment with a debugger. Being able to use a debugger is often a big aid for the attacker as it enables the attacker to stop code execution and monitor the application memory space and registers at any point of time.

The usual approach for implementing anti-debugging is trying to detect the debugger process and preventing it from hooking the target application. The big challenge is that the attacker may try to attach the debugger at any point of application execution. It is not enough to only perform such check when the application is starting, for example. Resolving this challenge is not trivial. Detailed knowledge about the debugger behavior is required, and the anti-debugging logic must be built to protect from all possible ways to utilize the debugger.

Whitebox cryptography

Whereas code or string obfuscation tries to obfuscate the static application data, it does not distinguish security critical data from other static data. Hence, any application containing data such as cryptographic keys needs to have a solution for protecting these critical assets. It may prove to be very difficult to protect the keys only, but there is an alternative solution: whitebox cryptography.

The target of whitebox cryptography is to be able to protect the cryptographic keys even in an environment subjected to a whitebox type of an attack. The usual approach to implement whitebox cryptography is to integrate the key for a cryptographic algorithm as part of the algorithm implementation itself. That means, the key becomes an inseparable part of the algorithm implementation.

The benefit here is that instead of using the cryptographic key in an application, it is possible to use whitebox implementation of the algorithm directly, and no keys are exposed to the attacker.  For example, one of the most commonly used cryptographic algorithms is AES algorithm. It has been a target for wide academic research from whitebox cryptography perspective, and it is also an essential algorithm to have in the product feature set for whitebox cryptography vendors.

Example case: INSIDE Secure tools
INSIDE Secure is an example of a state-of-the-art code protection tool vendor. Their Code Protection toolset can be run on a Qt application to both obfuscate the binary and static data including string, and make the Qt application self-protecting against tampering, irrespective of the integrity of the environment.

This makes it very hard to circumvent licensing checks, find out sensitive IPR, or breach the application integrity when processing financially valuable transactions.


A successful protection of an application is always a sum of its parts. As a developer, if you neglect one area, you will leave your application vulnerable to certain kind of attacks. Consequently, serious application protection is something that a normal developer should not try to implement by himself. There are a number of high quality tools available for just this purpose. Just go and pick the right one for you – and remember that a commercial license of Qt allows using these means of protecting your application or a device.

Can we help you?

Intopalo is a Qt Service Partner that specializes in software security. If you are not sure where to start, we are more than happy to give you a hand and guide you to the right direction. Visit Intopalo website for more information.

The post Protecting a Qt Application or a Device Against Hacking, Part 2 appeared first on Qt Blog.

Qt 5.11 Brings New Accessibility Backend on Windows

Accessibility technology encompasses assistive tools such as screen readers, magnifiers and braille displays, as well as APIs and frameworks that allow applications to expose elements of their UI to such tools.

While some UI widgets provided by the operating system may already be prepared to provide content and metadata to assistive tools, Qt renders UI elements itself. This approach requires a way to expose information about these elements to accessibility frameworks, which would otherwise perceive the applications as sets of empty windows.

To expose information about UI elements on Windows, Qt relied on the legacy Microsoft Active Accessibility framework (MSAA), until Qt 5.10. However, proper framework support was lacking in some areas, and nowadays MSAA has been superseded by a new framework and its use is no longer recommended for new applications.

With release 5.11 we will replace the MSAA accessibility backend with a new implementation based on the more modern Microsoft UI Automation, which superseded MSAA as the de facto standard for accessibility on the Windows platform. UI Automation has been available in all Windows releases since RTM versions of Windows 7 and Server 2008, as well as provided with system updates on Windows XP, Vista and Server 2003.

Since the accessibility changes in Qt 5.11 are internal, existing accessible applications are not expected to require any changes to utilize the improved functionality provided by UI Automation. Compatibility with MSAA-only assistive tools is maintained by bridge components built in the UI Automation framework itself.

One area where immediate improvement resulting from the new approach can be perceived is in the control of Qt-based applications using the built-in virtual keyboard in touchscreen-based Windows computers, like the Microsoft Surface line. In Qt 5.10, compatibility with some UI widgets was limited and events like the automatic showing and hiding of the virtual keyboard were not supported. With Qt 5.11, the same level of functionality available to applications based on native Windows widgets should be expected.

Also, the new UI Automation support in Qt may become useful for application testing, since it can provide metadata and programmatic control of UI elements, which can be leveraged by automated test suites and other tools.

We invite users to test the new accessibility functionality, and to give us feedback by writing to the mailing lists and reporting bugs.


The post Qt 5.11 Brings New Accessibility Backend on Windows appeared first on Qt Blog.

Qt 5.11 Alpha Released

Qt 5.11 Alpha is released today. As usual the official Alpha is a source code delivery only, but later we will offer development snapshots of Qt 5.11 regularly via the online installer.

Please check Qt 5.11 New Features wiki to see what new is coming with Qt 5.11 release. Please note that the feature list is still in progress and not to be considered final before the first Beta release.

Next milestone in our way to final Qt 5.11 release (which is planned to happen in May) will be first Beta release. We are targeting to get it out as soon as possible soon after the Alpha. We will release several Beta releases in similar manner as before, available via the online installer.

Please download the Qt 5.11 Alpha source packages from your Qt Account or from download.qt.io.

Most importantly, remember to give us feedback by writing to the mailing lists and reporting bugs.

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

Qt in Visual Studio: Improving Performance

In the last post, we discussed a new approach to design time and build time integration of external tools in Visual Studio using MSBuild rules and targets. This will be included in the upcoming release of version 2.2 of the Qt VS Tools. In this post, we will discuss the performance improvements that are also included in this new version.

We’ll focus on two situations where users of the current version (2.1) of the Qt VS Tools have reported sub-standard performance:

  • Adding new header files, especially to projects with many configurations
  • Converting Qt projects (.pro files) with many files

We’ll look at the scale of these problems and why they occur, then discuss the steps that have been taken to fix the problems and the improvements that have been achieved.

Adding Header Files to a Project

To understand the scale of this problem and the effectiveness of our solution, we ran the same set of tests using both the current and the new version. These tests consisted of adding several header files containing Qt macros to projects with varying numbers of configurations. For more information on the test setup and a detailed analysis of the results, please refer to the section “Measuring Performance”, at the end of this post.

Looking into the results of testing version 2.1, we found that the time to add files to a project got progressively worse, up to several minutes, the more configurations were defined in the projects. The worst case scenario was just under 45 minutes for adding 10 files to a project with 20 configurations. It was possible to determine that the performance degradation is closely related to the approach previously followed, where files generated by moc were explicitly added to the project in order to be included in the C++ compilation. The time spent modifying properties of generated files accounted for 98% of total time.

As we discussed in the previous post, the new approach based on MSBuild rules and targets allows source files to be added to the build process while it is ongoing. This way, instead of adding the files generated by moc as static project items, they are added dynamically to the C++ compilation during the processing of the moc target. This should represent a significant improvement to the cost of adding new header files to a project. The test results from version 2.2 show that this is indeed the case: the time spent on each test case was, on average, 95% less than that of version 2.1, and what was previously the worst case scenario (10 files added to a project with 20 configurations) now took only 3,2 seconds to complete.

This improvement in performance is not limited to the action of adding header files to projects. It will have an impact in all operations that handle generated files as project items. The following is a list of other use cases that should also benefit from the increase in performance (especially in projects with several configurations):

  • Importing Qt projects (see next section);
  • Creating new Qt classes;
  • Manually adding/removing the Q_OBJECT macro in a file;
  • Changing the Qt version;
  • Changing the path to the moc, rcc and uic generated files.

Importing Qt Projects

The problem described above also applies when importing a .pro file, since properties of generated files are also accessed and modified during import; in fact, the import procedure modifies properties of all project files. To avoid this problem, in the new version of the Qt VS Tools, the Visual Studio project that is generated by qmake is not immediately loaded into Visual Studio; all modifications are carried out as an XML transformation on the project file. Only then is it loaded into Visual Studio. This way we avoid any project-wide processing while the project is loaded.

To test this optimization, we imported the Qt example project demobrowser. Below is a recording of this test using version 2.1 (left) and version 2.2 (right) of the Qt VS Tools (the recording also includes building and running the program). We found that the time to import the project decreased from over 30 seconds in the current version to less than 6 seconds in the new version.

Importing demobrowser


Measuring Performance

To measure the scale of the performance problem when adding new header files, we ran a series of tests with an instrumented build of the Qt VS Tools that recorded the number and duration of calls to every function. As the performance seemed to be influenced by the number of project configurations, we tested with several projects containing respectively 2, 5, 10, 20 and 40 configurations. As the number of files added also seemed to be a factor, we tested each project with 5, 10, 20 and 40 files added, for a total of 20 test cases. We will use the variable C to represent the number of configurations, and the variable F to represent the number of files added.

The results of testing with version 2.1 of the Qt VS Tools show that the performance degrades significantly as we increase the number of configurations and the number of files added. The graph below summarizes the test results. Some tests were interrupted after 45 minutes; this is noted in the graph by grayed-out bars. The blue bar on the left serves as a 1 minute scale.

Test Results v2.1

Looking further into the test data, we find that most of the elapsed time was spent calling functions of the Visual Studio SDK. For example, in the test case C=20,F=10, which took almost 45 minutes to complete, 98% of that time was spent in the following calls:

Calls to Visual Studio SDK

These functions were called while adding generated files to the project – files generated by moc must be added to the project in order to be included in the C++ compilation. For every header file added, one generated file per configuration will also be added to the project, i.e. F×C generated files. In the test case of C=20,F=10, this accounts for the 200 calls, e.g. to the AddFile function.

Each one of the F×C generated files can only be compiled if the corresponding project configuration is active. For all other configurations, the file must be set to “excluded from build”. This is the reason for the larger number of calls to the set_ExcludedFromBuild function, i.e. F×C×(C-1) calls to that function. In the example of the C=20,F=10 test case, this accounts for the 3800 calls to set_ExcludedFromBuild.

We’ve also found that the functions of the Visual Studio SDK tend to become slower as the number of calls increases. In the case of set_ExcludedFromBuild, we see that the average time per call went from 11 milliseconds, when calling the function 10 times, to 535 milliseconds per call for 3800 calls:

Calls to set_ExcludedFromBuild

With the approach followed in version 2.1, which requires that generated files be added to the project, there doesn’t seem to be much room for improvement in performance: almost all time is spent inside external functions and these functions are called exactly the number of times needed. The problem of the performance degradation seems then directly linked to the approach itself.

To test the performance of the new approach, we ran the same 20 test cases using the new version 2.2 of the Qt VS Tools, which uses the Qt/MSBuild targets; the results are shown in the graph below. As before, the blue bar on the left represents the same 1 minute scale.

Test Results v2.2

Comparing the results of both tests, in version 2.2 the time spent was, on average, 95% less than that of version 2.1. The average cost of adding header files to a project, per file and configuration (i.e. total time divided by F×C), decreased from 300 milliseconds to 40 milliseconds.

The post Qt in Visual Studio: Improving Performance appeared first on Qt Blog.

Cutelyst on TechEmpower benchmarks round 15

On Valentines day TechEmpower released the results of fifth round of it's benchmarks tests on web frameworks, it took almost a year since round 14 and I really hope round 16 comes out sooner.

Since this round took a long time and was scheduled to be release many times last year I decided not to update Cutelyst to avoid not having the chance to fix any issues and have broken results. Cutelyst 1.9.0 and Qt 5.9 were used, both had some performance improvements compared to round 14, and thus you can see better results on this round compared to 14, most notably the JSON tests went from 480k request/second to 611k req/s, also due this Cutelyst release used jemalloc was again not used due a bug we had in CMake files that didn't link against it.

In this round some  other frameworks have also done their optimizations and a few managed to do better than Cutelyst, even though we were faster in all tests compared to the last round. It might be even related to some OS tuning as most results seemed to went up a bit, however if you put the filter on "FullStack" frameworks Cutelyst is leading in most tests.

TreeFrog framework had results in TechEmpower long before I wrote the tests for Cutelyst, but due errors on TreeFrog tests on last rounds this was the first round where you can compare the results of two Qt Web Frameworks.

For the next round I expect the results to be even better now that we will properly use jemalloc, and our epoll dispatcher got a better implementation, I also plan to use Cutelyst 2 and try increasing some buffers as the servers have plenty of RAM that I didn't care on using.

If you want to know more about Cutelyst visit https://cutelyst.org/ and give us a Star on GitHub (we are now past 300!!) https://github.com/cutelyst/cutelyst

Web Editor: Test Online Code Examples on Android and iOS with Live Code Reloading

Did you ever wonder how to quickly test online code examples? Did you ever see a code example and thought “I would love to try that right away”?

V-Play got you covered! With the V-Play Web Editor, you can run code examples on your Android or iOS phone, right from your desktop browser. It’s a Cloud IDE for editing, running and debugging QML Code. You don’t need to install any native SDKs or development environment like Qt Creator on your computer. You don’t even need to install the V-Play SDK or Qt SDK. All you need is to download the V-Play Live Scripting app for Android or iOS.

1. Download the V-Play Live Scripting App

The V-Play Live Scripting app is available on Android and iOS. Download it to use Live Code Reloading from your browser or desktop.

Google_Play_Badge-1App Store
ic_launcherV-Play & QML Live Scripting App
Search in App Stores for: “V-Play Live Scripting”

2. Run Code Examples from Documentation and Blog with the V-Play Web Editor

You can find the V-Play Web Editor for Qml code at https://v-play.net/web-editor/.


For convenience you can also find a button above all code examples in our documentation and on the blog. Click on it to open the example in the Web Editor. Here is an example that you can try right away (make sure you read this post on your desktop!):

import VPlayApps 1.0
import VPlay 2.0
import QtQuick 2.8

App {
  NavigationStack {
    Page {
      title: "My First App"

      AppButton {
        anchors.centerIn: parent
        text: "Celebrate"
        onClicked: {
          nativeUtils.displayAlertDialog("Yay", "That is so cool!")

There are some more cool examples at the end of this post, make sure to give them a try!

3. Test on Android and iOS at the Same Time

You can connect all your mobile phones to the Web Editor at the same time. This means you can test how an example looks on different platforms simultaneously.

The Web Editor also displays log output of your connected devices.



4. Live Code Reloading in your Browser

You would like to change the example code a bit? No problem!

You can edit the code in the Web Editor and click the run button, or hit CTRL+S (CMD+S on macOS). The code reloads on your mobile phone immediately and shows the new result.

It is also possible to write your own code, or copy/paste any example to the Web Editor. You get the full log output of any connected mobile phone, to find possible errors in your code.

Cloud IDE Benefits for You

The biggest benefit was already highlighted in the introduction of this post. You can test code examples right away on your mobile phone from the browser. This works without installing any SDK on your desktop.

Besides that, it is also useful for developers that already have everything installed. You save the effort to create a new project to test an example. You can explore the documentation and test any interesting example with only a button click.

With Live Code Reloading, you can tweak the example within your browser until it fits for you.

Live Code Reloading on Desktop, Android and iOS

You can also use the V-Play Live Scripting app for development on desktop. You can find more info about V-Play Live Code Reloading in this post.


What’s Next for the V-Play Cloud IDE for QML

Currently the run button might also be displayed for code examples in the documentation that will not run successfully.

The majority of examples and code snippets from the V-Play Apps documentation is working fine already, and while you’re reading this the games documentation is finalized as well. This means you can already start working with the Web Editor and start saving development time!

We will update the V-Play Live Scripting app next week with an improved user interface and a project cache. You will be able to open your projects on your mobile phone also when not connected to your desktop, to show it to friends, customers or to yourself. :)

The next steps are then support for autocompletion, integrated help and Git support. This allows you to work on the same project on Desktop (with Qt Creator or any other IDE you prefer) and the web, with the V-Play Cloud IDE for QML code.

More QML Code Examples

QML Map Example


Displays a map using the MapBox service.

import VPlayApps 1.0
import QtLocation 5.5

App {
  NavigationStack {
    Page {
      title: "Map Example"
      // show the map
      AppMap {
        anchors.fill: parent
        plugin: Plugin {
          name: "mapbox"
          // configure your own map_id and access_token here
          parameters: [  PluginParameter {
              name: "mapbox.mapping.map_id"
              value: "mapbox.streets"
            PluginParameter {
              name: "mapbox.access_token"
              value: "pk.eyJ1IjoiZ3R2cGxheSIsImEiOiJjaWZ0Y2pkM2cwMXZqdWVsenJhcGZ3ZDl5In0.6xMVtyc0CkYNYup76iMVNQ"
            PluginParameter {
              name: "mapbox.mapping.highdpi_tiles"
              value: true

QML List  Example


Shows a simple list with a button to add new list items.

import VPlayApps 1.0

App {
  NavigationStack {
    Page {
      id: page
      title: "Add List Items"
      // the data model for the list
      property var dataModel: [
        { text: "Item 1" },
        { text: "Item 2" },
        { text: "Item 3" }
     // button to add an item
      AppButton {
        id: button
        anchors.horizontalCenter: parent.horizontalCenter
        text: "Add Row"
        onClicked: {
          // create and add new item
          var itemNr = page.dataModel.length + 1
          var newItem = { text: "Item "+itemNr }
          // signal change in data model to trigger UI update (list view)
     // list view
      AppListView {
        id: listView
        anchors.top: button.bottom
        anchors.bottom: parent.bottom
        width: parent.width
        model: page.dataModel
        delegate: SimpleRow {}

QML AdMob Ad Banner Example


Shows the easy integration of a native AbMob ad banner.

import QtQuick 2.0
import VPlayApps 1.0
import VPlayPlugins 1.0

App {
  NavigationStack {
    Page {
      title: "AdMob"

      AdMobBanner {
        adUnitId: "ca-app-pub-3940256099942544/6300978111"

QML Physics Example


Simple game example where gravity pulls a ball downwards.

import VPlay 2.0
import QtQuick 2.8

GameWindow {
  Scene {
    EntityManager {
      id: entityManager

    // gravity will pull the ball down
    PhysicsWorld {
      gravity.y: 9.81

    // just a simple ball shaped entity
    EntityBase {
      id: entity
      width: 20
      height: 20
      x: 160
      y: 240

      Rectangle {
        anchors.fill: parent
        color: "red"
        radius: 10

      // the collider enables physics behavior
      BoxCollider {
        id: collider
        anchors.fill: parent

    // this timer resets the ball after 3 seconds
    Timer {
      running: true
      interval: 3000
      repeat: true
      onTriggered: {
        entity.x = 160
        entity.y = 240
        collider.linearVelocity = Qt.point(0,0)


You can find more code examples everywhere in our documentation.

The code snippets page is a compilation of several useful code examples for apps.
Go to Code Snippets Page



More Posts Like This


Release 2.14.0: Live Code Reloading for Desktop, iOS & Android


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

The post Web Editor: Test Online Code Examples on Android and iOS with Live Code Reloading appeared first on V-Play Engine.