Tap, Tinder and Touchscreens: How Swipe Can Improve the User Experience

Tap is the safest touch gesture. Everyone understands that tap equals click. On a touchscreen, you tap where you would have pointed and clicked on a mouse-enabled display. Tap is a simple, deliberate gesture. The presence of a button-like element is indication enough that it can be tapped, and will likely mean yes or no, save or cancel, choose this thing or navigate to this new place.

Over-the-Air Updates, Part 2: Device Integration, API and Creating Updates

With Qt 5.7 for Device Creation we introduced a new piece of technology – an OSTree-based solution for Over-the-Air software updates for the whole software stack. For a more detailed introduction about this new component of the Boot to Qt software stack, read part one of the blog post series. This blog post contains a step-by-step guide on how to add OTA update capability to your Boot to Qt device, discusses Qt OTA API and finally demonstrates how to generate OTA updates for shipped devices.

Device Selection.

For this tutorial we are going to use the Intel NUC board – a new reference device in Qt 5.7 for Device Creation. Intel NUC is a low-cost, pint-sized powerhouse solution for a wide variety of fields, including Internet of Things where OTA update capability is especially desired. I chose this board for the tutorial because it is not your traditional ARM-based embedded Linux board that uses the U-Boot bootloader. Instead, Intel NUC is a x86-64 target with the GRUB 2 bootloader. The OTA solution in Technology Preview supports U-Boot and GRUB 2 bootloaders, and adding support for additional bootloaders is a straightforward task (as long as a bootloader has the means to read from an external configuration file).

Device Integration Steps.

I won’t go into too much detail at each step, as that is already covered in the OTA documentation. The goal of this tutorial is to show the necessary steps to add OTA capability to a device and to demonstrate that it doesn’t require months of effort to add such a capability. Rather, it takes just a few hours when using the OTA solution from Qt for Device Creation.

1. Generate OSTree boot compatible initramfs image.

This step requires booting the device with the sysroot to be released, so that the tool can generate initramfs that match the kernel version of the release. The device has to be connected to the machine from which you will run the generate-initramfs tool:


2. Bootloader integration.

This is the only step that requires manual work. The bootscript used by your device has to be changed to use the configurations that are managed by OSTree. This will ensure that, after OTA updates or rollbacks, the correct kernel version (and corresponding boot files) will be selected at boot time. On U-Boot systems this requires sourcing uEnv.txt and then integrating the imported environment with the bootscript. On GRUB 2 systems, whenever the bootloader configuration files need to be updated, OSTree executes the ostree-grub-generator shell script to convert bootloader-independent configuration files into native grub.cfg format. A default ostree-grub-generator script can be found in the following path:


This script should be sufficient for most use cases, but feel free to modify it. The ostree-grub-generator file contains additional details. The script itself is about 40 lines long.

3. Convert your sysroot into an OTA enabled sysroot.

The conversion is done using the qt-ostree tool.

sudo ./qt-ostree \
--sysroot-image-path ${PATH_TO_SYSROOT} \
--create-ota-sysroot \
--ota-json ${OTA_METADATA} \
--initramfs ../dracut/initramfs-${device}-${release} \
--grub2-cfg-generator ${CUSTOM_GENERATOR}

This script will do all the necessary work to convert your sysroot into an OTA enabled sysroot. The ${OTA_METADATA} is a JSON file containing the system’s metadata. The following top-level fields have convenience methods in the Qt/QML OTA API: version and description. The API provides the means of manually fetching and parsing the file (which consequently can contain arbitrary metadata describing the sysroot).

4. Deploy the generated OTA image to an SD card.

sudo dd bs=4M if=<image> of=/dev/<device_name> && sync

5. Test that everything went according to plan.

Boot from the SD card and run the following command from the device:

ostree admin status

The output should be something similar to:

* qt-os 36524faa47e33da9dbded2ff99d1df47b3734427b94c8a11e062314ed31442a7.0
origin refspec: qt-os:linux/qt

Congratulations! Now the device can perform full system updates via a wireless network. Updates and rollbacks are atomic and the update process can safely be interrupted without leaving the system in an inconsistent state. If an update did not fully complete, for example due to a power failure, the device will boot into an unmodified system. Read about the other features of the update system in the OTA documentation.

User Space Integration.

With the device being OTA capable, we need to take advantage of that. We provide C++ / QML APIs to make OTA update functionality integration with Qt-based applications a breeze. Offline operations include querying the booted and rollback system version details and atomically performing the rollbacks. Online operations include fetching a new system version from a remote server and atomically performing system updates. A basic example that demonstrates the API:

Label { text: "CLIENT:"; }
Label { text: "Version: " + OTAClient.clientVersion }
Label { text: "Description: " + OTAClient.clientDescription }
Label { text: "Revision: " + OTAClient.clientRevision }

Label { text: "SERVER:"; }
Label { text: "Version: " + OTAClient.serverVersion }
Label { text: "Description: " + OTAClient.serverDescription }
Label { text: "Revision: " + OTAClient.serverRevision }

Label { text: "ROLLBACK:"; }
Label { text: "Version: " + OTAClient.rollbackVersion }
Label { text: "Description: " + OTAClient.rollbackDescription }
Label { text: "Revision: " + OTAClient.rollbackRevision }

RowLayout {
    Button {
        text: "Fetch OTA info"
        onClicked: OTAClient.fetchServerInfo()
    Button {
        visible: OTAClient.rollbackAvailable
        text: "Rollback"
        onClicked: OTAClient.rollback()
    Button {
        visible: OTAClient.updateAvailable
        text: "Update"
        onClicked: OTAClient.update()
    Button {
        visible: OTAClient.restartRequired
        text: "Restart"
        onClicked: log("Restarting...")

The above sample presents version information for the booted and rollback system, as well as what system version is available on a remote server. The sample program also contains buttons to initiate OTA tasks. The code below is used for logging OTA events. The API is still in Technology Preview, so the final version might have slight changes.

Connections {
    target: OTAClient
    onErrorChanged: log(error)
    onStatusChanged: log(status)
    onInitializationFinished: log("Initialization " + (OTAClient.initialized ? "finished" : "failed"))
    onFetchServerInfoFinished: {
        log("FetchServerInfo " + (success ? "finished" : "failed"))
        if (success)
            log("Update available: " + OTAClient.updateAvailable)
    onRollbackFinished: log("Rollback " + (success ? "finished" : "failed"))
    onUpdateFinished: log("Update " + (success ? "finished" : "failed"))

This API could easily be used to write a daemon that communicates its version details to the server and the daemon could send a notification to the user when an update becomes available. The server could send out updates in batches, first updating a small subset of devices for field testing, fetching update statuses from daemons and if there are no issues, update the remaining devices. Some tools for this type of tasks are in the roadmap of OTA solution for the Boot to Qt stack.

Ship it! Some time later … a critical bug emerges.

As we took a precaution and built an embedded device with OTA capability as well as creating a Qt application for handling updates, there are only few simple steps to follow to resolve the issue.

1. Fix the bug.

I will leave the details up to you 😉 We will use the updated sysroot in the next step.

2. Generate an update.

This is done by using the qt-ostree tool. Generating an OTA update is a completely automated task.

sudo ./qt-ostree \
--sysroot-image-path ${PATH_TO_SYSROOT_WITH_THE_FIX} \
--initramfs ../dracut/initramfs-${device}-${release}

The above command will create a new commit in the OSTree repository at WORKDIR/ostree-repo/, or create a new repository if one does not exist. This repository is the OTA update and can be exported to a production server at any time. OSTree repositories can be served via a static HTTP server (more on this in the next blog post).

3. Use Qt OTA API to update devices.

It is up to system builders to choose an update strategy.


The Boot to Qt project leverages The Yocto Project to built its own distribution layer called meta-boot2qt. The Boot to Qt distribution combines the vendor specific BSP layers and meta-qt5 into one package. This distribution is optimized to make the integration with the OTA tooling as simple as possible. All source code is available under commercial and GPL licenses.


Enabling the OTA update feature on Boot to Qt devices is a quick and worthwhile task. With OTA enabled devices you can ship your products early and provide more features later on. In the next blog post I will write about OSTree (OTA update) repository handling, remote configuration and security.

The post Over-the-Air Updates, Part 2: Device Integration, API and Creating Updates appeared first on Qt Blog.

Qt Certification

It has been possible to attend a Qt certification exam and become a Certified Qt Developer or Qt Specialist since 2009. Now the exams and certifications have been updated to cover the latest Qt features. In order to support providers of quality Qt training and ease developers’ preparation for the exams, we are also launching a Qt training partner program.

Developer Certificate

There are three kinds of exams as before: Qt and QML Essentials, Widget UI and Application Engine with Qt, and Qt Quick UI. Candidates, passing the essentials exam, are given the Certified Qt and QML Developer statuses. Compared to the previous essentials exam, basic knowledge of QML, such as elements, layouts, and user interactions, are required in the updated version. After the essentials exam, candidates may choose to become a Certified Qt C++ Specialist or Certified Qt Quick Specialist or even both. To become a Qt C++ Specialist, a candidate needs to pass the Widget UI and Application Engine with Qt exam, which tests the candidate’s knowledge about threading, databases, XML and JSON, networking, and model/view framework in addition to widgets. In a similar way, the Qt Quick UI exam tests the attendee’s knowledge about several Qt Quick and QML modules, such as Qt Quick Controls, particle system, multimedia, custom modules and new Qt Quick types. The exact curriculums are available at https://www.qt.io/qt-certification/.

In each exam, the candidates have 60 minutes to answer a number of multiple choice questions. The essentials exam consists of 50 questions, from which 31 must be correctly answered to pass the exam. Advanced exams contain 30 questions, from which 16 must be answered correctly. Coding is not required, but many questions contain a code snippet, which must be understood to pick up the correct answer or answers. Exams can be attended in any Pearson VUE authorized test center around the world. The details of test center locations and instructions how to make an appointment and attend an exam can be found at http://www.pearsonvue.com/qtcompany/. The exam price varies from test center to test center, so the exact price should be asked directly from the test center.

Certified Developers and Specialist will receive a printed certificate with 2-4 weeks after the exam.

The best way to prepare for the exams is, besides to write Qt programs covering all the curriculum topics, to attend a Qt training course. The Qt Company are now launching a Qt training partner program, where we make up-to-date training material available to providers of Qt training. All training under the program will be done by qualified trainers. Qt courses for open enrollment will be advertised on our web site: http://www.qt.io/qt-training/. Our hope is that over time this program will benefit Qt developers everywhere.

Good luck with your preparations and with your exams!

The post Qt Certification appeared first on Qt Blog.

Enabling Connectivity in Your Embedded Product

by Sebastien Ronsse, Adeneo Embedded [Qt Service Partner] (Qt Blog)

Building embedded products today, regardless of the targeted market, not only involves creating a nice, user-friendly interface, but often requires interoperability and connectivity. Mixing web technologies with native content has come a long way and can now easily produce attractive and powerful applications.

When bringing connectivity to embedded products, some existing web technologies can be paired with a framework, such as Qt, to create best-in-class applications.

HTML5 technology is now standardized, well adapted for touch-screen navigation, and mature enough to run on embedded devices. Qt offers support for this through its WebEngine web content rendering engine based on Chromium. Mixed content is also possible, allowing users to write a typical application using QML and have dedicated HTML5 content as part of the solution.

Mobile and remote access

If there is a requirement to remotely access a device while providing the same or at least a subset of the embedded user interface, this is possible using HTML5 content within a Qt application. The result is that a team can develop and design an interface once and have it available on a myriad of devices.

Adeneo has used the i.MX6 SoloX to demonstrate this concept: an accelerometer sensor is sampled and an HTML5 graph displaying the different acceleration components is rendered within a Qt application. That same graph is also advertised remotely, accessible from any browser, allowing real-time view via tablets, mobile phones, regular computers or even other embedded devices.

Taking advantage of node.js

Node.js is a JavaScript runtime built on Chrome’s V8 JavaScript and, when paired with other frameworks such as MongoDB, Express.js, and Angular.js, it provides a powerful, lightweight, and proven web stack. If you are interested in linking your embedded product with the Cloud, node.js is a popular cross-platform choice and is backed by services such as Microsoft Azure and Amazon AWS.

Qt can also be combined with 3D rendering techniques using technologies such as OpenGLES. A favorite example of mine is the Heart Rate Monitor demonstration Adeneo developed on the Renesas RZ/G1E Starter Kit, showing a real-time 3D model of a heart rendered with advanced shaders on the platform using Qt 5.4. This application works jointly with a node.js backend, and displays the heart rate pulse via HTML5 to clients connected to the device remotely through Web Sockets. This illustrates how Qt can easily be used in conjunction with such technologies, helping to create an all-in-one connected solution.

The latest flavors of Qt provide an optimized web engine and web view tandem. This provides developers with a cross-platform, all-in-one solution for building advanced web applications with minimal risk and development time. Producing hybrid applications is made possible through integration between these web-oriented components and the QML language, which can significantly reduce overall project costs as well as simplifying development.

Learn more about Adeneo’s Qt expertise here: http://www.adeneo-embedded.com/OS-Technologies/Qt

The post Enabling Connectivity in Your Embedded Product appeared first on Qt Blog.

What You Need to Know about the GNU LGPL

Qt 5.7 was released last week and as discussed in the release blog post, it is the first release that follows the new open source licensing scheme where we’ve unified the Qt for Application Development offering but also upgraded the LGPLv2.1 license to LGPLv3.

Qt has been available under LGPL for several years, and the license issues are naturally complex ones. To help you understand the obligations of the LGPLv3, we would like to introduce you this video done by Dr. Till Jaeger from JBB Rechtsanwälte, a recognized international legal expert on open source issues. The video goes through the background information about the GNU LGPLv3 and then addresses the separate rights you have under the LGPLv3.

In addition, to make the correct licensing choice, you can also take a look at our licensing pages, the licensing FAQ or the licensing comparison table at our web page.

Hope you find the video useful and enjoy Qt 5.7!

The post What You Need to Know about the GNU LGPL appeared first on Qt Blog.

Qt 5.6.1-1 Released

We have today released Qt 5.6.1-1, which fixes a critical problem in Qt 5.6.1 preventing certain type of Qt Quick applications from working properly. I am very sorry for the inconvenience, but those who have already downloaded Qt 5.6.1 now need to get the new Qt 5.6.1-1 release. The problem is already fixed in the Qt 5.7.0 released last week.

The problem with Qt 5.6.1, reported in QTBUG-53761, is that certain Qt Quick applications crash after some time. The problem occurs with code that loads more than 64 components (.qml or .js files) without instantiating objects from all of them. The components that initially don’t get instantiated will then be removed from the type cache, which causes problems if you later try to instantiate objects from them. Reason for the problem is too aggressive trimming of the QML type cache, which ends up deleting some QML types even though they were still in use by the application.

This bug was noticed and fixed just slightly too late for Qt 5.6.1 with https://codereview.qt-project.org/#/c/161888. It got into the 5.6 branch as well as into Qt 5.7.0 release last week. Furthermore, as the bug was a bit difficult one to diagnose, it was initially slightly misdiagnosed resulting it to be P1, not P0 as it should have been.

If you are using the online installer, Qt 5.6.1-1 can be updated using the maintenance tool. Offline packages are available for commercial users in the Qt Account portal and at the qt.io Download page for open-source users.



The post Qt 5.6.1-1 Released appeared first on Qt Blog.

Qt on Android: How to restart your application

Some time ago, I wrote a code to restart the running application on Android.

You might well ask why such a thing was needed. It was needed because there are cases where, whenever a user changes the theme, the application has to restart to apply the change (it can’t be applied on the fly). In my example I used it to restart Qt Quick Controls 2 gallery.

Sadly my fix was not accepted, because other platforms (iOS, IIRC) have this missing feature too, so it was decided to remove Android code so it didn’t stand out.

Anyway, because I think this piece of code might help other people, I’m going to share it with you today.

Our goal is to use AlarmManager.set() method to set an alarm (a PendingIntent) that will start our application in the near future (in our case 100ms from now), then quits the application. When the alarm timeouts it will start our application. Be aware that the AlarmManager is anything but accurate, so it might take more than 100ms to restart the application (in some cases it takes up to 5s to restart it).

Here is the code that does all the magic:

auto activity = QtAndroid::androidActivity();
auto packageManager = activity.callObjectMethod("getPackageManager",

auto activityIntent = packageManager.callObjectMethod("getLaunchIntentForPackage",

auto pendingIntent = QAndroidJniObject::callStaticObjectMethod("android/app/PendingIntent", "getActivity",
                                                               activity.object(), jint(0), activityIntent.object(),

auto alarmManager = activity.callObjectMethod("getSystemService",

                              QAndroidJniObject::getStaticField<jint>("android/app/AlarmManager", "RTC"),
                              jlong(QDateTime::currentMSecsSinceEpoch() + 100), pendingIntent.object());


Let’s have a closer look to the code:

  • 1st line gets the activity packageManager object.
  • 2nd line gets an activityIntent object using the packageManager. getPackageName() method returns the name of this application’s package name.
  • 3rd line gets a pendingIntent needed to restart our application.
  • 4th line gets the alarmManager
  • 5th line sets the pendingIntent to start 100 milliseconds from now.
  • 6th line quits the application

The post Qt on Android: How to restart your application appeared first on KDAB.

Adding Live Translation to BlackBerry 10 C++ Code


Editor:  Today we have a guest post from Martin Green.  Martin spent nearly a decade repairing marine navigational equipment on “Lakers” and “Salties”, such as RADAR, Loran C, gyrocompasses, and early SatNav, followed by twenty-five years as a contract Enterprise software developer for governments, banks, and major corporations before coming to mobile and BlackBerry 10 Native development in early 2013. He is the owner of arsMOBILIS and the developer of multiFEED, an RSS/Atom reader app available in BlackBerry World.

If you have built (or are building) your BlackBerry 10 Native Cascades apps with internationalization in mind then you likely have code peppered with QML qsTr() calls and C++ tr() macros. When your app starts up the text wrapped in qsTr() or tr() is substituted with the localized text for the device locale and language (if defined, otherwise default translation is used). This works fine unless you change the language setting on your device while your app is running. Unless you take steps to propagate the language change through your live app, the text displayed in your UI will not match the new device language setting until the page is reloaded or your app is restarted. QML provides for this “live translation” with the Retranslate class which can be used with qsTr() to update translations as soon the device language setting is changed:

Page {
    Container {
        Label {
         id: label01

         // ---This label's text will be live translated
         text: qsTr("Label 1") + Retranslate.onLanguageChanged
      Label {
         id: label02

         // ---This label's text will be static translated
         text: qsTr("Label 2")

In this example label01 will have its text attribute live translated so that it is updated as soon as the device language is changed. On the other hand label02 will only have its text translated when the app is first started and subsequent language changes while the app is running will not update it.

Using the Retranslate class with QML makes live translation as simple as adding a small amount of code right after every use of qsTr(), but C++ provides no such convenience. To implement live translation in C++ code it is necessary to call the setXXX() slot for a string attribute with the tr() macro once to do the initial translation then connect the setXXX() slot to a LocaleHandler instance which emits a signal every time the language (or locale) changes. This is complicated by the fact that the LocaleHandler knows that the language has changed, but it doesn’t know which text key to supply to the slots it is attached to so we have to attach the LocaleHandler signal to an intermediary slot which knows what translation key to use for that attribute and which then emits another signal with the key as a parameter which must be connected to the control setXXX() slot. This means that for every single control attribute you want to live translate you will need a separate intermediary slot defined somewhere, a related signal for that slot with a QString argument, and two QObject::connect() calls. For every attribute we want to live translate. Obviously this gets very ugly, very fast.

I prefer to use C++ with little or no QML to lay out my app pages so I was determined to find a solution which was as easy to use as Retranslate in QML (or nearly so) and after some trial and error I came up with a solution I’m very happy with, which I called LiveTranslator. The core of this technique is a new C++ class called LiveTranslator. The usage syntax is a little more complicated than using QML Retranslate, but like Retranslate you only need to add one line of code for each attribute you want live translation on. Here is the header for LiveTranslator:


#include <bb/cascades/LocaleHandler>

using namespace bb::cascades;

class LiveTranslator: public QObject {

    QString _key;
    QString _context;

    static LocaleHandler* _localeHandler;

    LiveTranslator( const QString& context,
            const QString& key,
            QObject* target,
            const char* slot );

    static void setLocaleHandler( LocaleHandler* localeHandler );

private slots:
    void localeOrLanguageChangedHandler();

    void translate( const QString& string );


…and the body…

#include "LiveTranslator.hpp"

/* ---Initialize the locale handler pointer on app startup so we can tell if it
has been set properly later */
LocaleHandler* LiveTranslator::_localeHandler = 0;

/* ---Note that the target control is also used as the parent so the live translator dies when the control does */
LiveTranslator::LiveTranslator( const QString& context,
        const QString& key,
        QObject* target,
        const char* slot ) :  QObject( target ) {

    bool success;
    Q_UNUSED( success );

    // ---Save the context and key string
    this->_key = key;
    this->_context = context;

    // ---Die (during debug) if locale handler wasn't set properly before use
    Q_ASSERT( LiveTranslator::_localeHandler );

    // ---Watch for locale or language changes
    success = QObject::connect(
        SIGNAL( localeOrLanguageChanged() ),
        SLOT( localeOrLanguageChangedHandler() )
    Q_ASSERT( success );

    // ---Trigger specified slot when locale or language changes
    success = QObject::connect(
        SIGNAL( translate( const QString& ) ),
    Q_ASSERT( success );

void LiveTranslator::localeOrLanguageChangedHandler() {
    /* ---Use the specified slot on the target to update the appropriate string
    attribute with the translated key */
    emit translate(

/* ---This function MUST be called once with a valid LocaleHandler before any
LiveTranslator classes are instantiated */
void LiveTranslator::setLocaleHandler( LocaleHandler* localeHandler ) {
    LiveTranslator::_localeHandler = localeHandler;

LiveTranslator encapsulates all the ugly stuff, including remembering the translation key, the intermediary slot/signal, and all signal/slot connections necessary for live translation. Using it is as simple as creating an instance of LiveTranslator, passing the constructor the translation key for the attribute (and the context, but more on that later), the target UI control, and the slot on that component that will accept the updated translation. Note that tr() only works with static key strings…

// ---This is valid
QString str1 = tr("string one");

// ---This is not!
Qstring str1 = "string one";
QString str2 = tr(str1);

…so rather than tr(), LiveTranslator must use QCoreApplication::translate() internally.

An example of LiveTranslator usage:

MyClass::MyClass() {
    Label* label = Label::create().text( tr("Label one") );
    new LiveTranslator( "MyClass", "Label one", label,
        SLOT(setText(const QString&)) );
    Option* option = Option::create().text( tr("Option one") )
        .description( tr("Option one description") );
    new LiveTranslator( "MyClass", "Option one", option,
        SLOT(setText(const QString&)));
    new LiveTranslator( "MyClass", "Option one description", option,
        SLOT(setDescription(const QString&)));
    ActionItem* actionItem = Option::create().title( tr("Action one") );
    new LiveTranslator( "MyClass", "Action one",
        actionItem, SLOT(setTitle(const QString&)));

Note that there is no need to save a reference to the new LiveTranslator instance since the constructor sets the “target” control as the parent. When the control is destroyed by your app the LiveTranslator will go with it. Also note that Momentics doesn’t know anything about LiveTranslator so you won’t be warned in the editor if the slot you provide is not valid. There is a Q_ASSERT in LiveTranslator though so you will know if the connection failed when testing your app in Debug mode.

The first parameter for the LiveTranslator constructor is the “context” where the translation key is located. When you use the tr() macro (or QML qsTr() function) the code parser makes note of where it found the key and stores it in the translation file along with the key. This way you could use the same translation key on different pages, and if the context is different you could have them translated differently. Again, the Index parser doesn’t know anything about the LiveTranslator class though so you have to tell it the context explicitly. For C++ the context is always the name of the class containing the code you are translating. Also, in case it isn’t obvious, the “key” parameter must be the same value as the one used with tr() on the line before it.

There is one thing you must do before using LiveTranslator in your C++ code and that is to give it a LocaleHandler to work with. Rather than force you to pass a LocaleHandler to every instance of LiveTranslator, you tell LiveTranslator which one to use just once with a static function call. If you created your app from one of the Momentics templates then you already have a handler you can use:

#include “LiveTranslator.hpp”

ApplicationUI::ApplicationUI() : QObject() {
    // prepare the localization
    m_pTranslator = new QTranslator( this );
    m_pLocaleHandler = new LocaleHandler( this );
    // Use this locale handler for all the live translations too
    LiveTranslator::setLocaleHandler( m_pLocaleHandler );


If all you care about live translating are normal UI components, then you have all you need now to easily implement live translation in your C++ code. If, however, you also want to have LiveTranslator work with certain system controls, such as SystemUiButton or SystemDialog you have a little more work ahead of you. The problem is that on these classes the attributes we would want to live translate are set with functions, not slots. This means that there is no way to tell LiveTranslator how to update the desired strings since it only works with Qt slots. The solution is quite simple though, all we need is to define a “helper” class for each system component type which can provide access to the setting function via slots. Here is a helper class for SystemUiButton

 * SystemUIButtonTrxHlp.hpp


#include <bb/system/SystemUiButton>

using namespace bb::system;

class SystemUiButtonTrxHlp: public QObject {

    SystemUiButton* _button;
    SystemUiButtonTrxHlp( SystemUiButton* button );

public slots:
    void setLabel( const QString& label );


 * SystemUiButtonTrxHlp.cpp

#include "SystemUiButtonTrxHlp.hpp"

SystemUiButtonTrxHlp::SystemUiButtonTrxHlp( SystemUiButton* button ) :
        QObject( button ) {
    this->_button = button;

void SystemUiButtonTrxHlp::setLabel( const QString& label ) {
    this->_button->setLabel( label );

As with LiveTranslator the constructor automatically makes the target button the parent, so you can create an instance of the helper and forget it. Now a similar helper for SystemDialog

 * SystemDialogTrxHlp.hpp


#include <bb/system/SystemDialog>

using namespace bb::system;

class SystemDialogTrxHlp : public QObject {

    SystemDialog* _dialog;

    SystemDialogTrxHlp( SystemDialog* dialog );

public slots:
    void setBody( const QString& text );
    void setRememberMeText( const QString& text );
    void setTitle( const QString& title );


 * SystemDialogTrxHlp.cpp

#include "SystemDialogTrxHlp.hpp"

SystemDialogTrxHlp::SystemDialogTrxHlp( SystemDialog* dialog ) :
        QObject( dialog ) {
    this->_dialog = dialog;

void SystemDialogTrxHlp::setBody( const QString& title ) {
    this->_dialog->setBody( title );

void SystemDialogTrxHlp::setRememberMeText( const QString& text ) {
    this->_dialog->setRememberMeText( text );

void SystemDialogTrxHlp::setTitle( const QString& title ) {
    this->_dialog->setTitle( title );

Now let’s create a SystemDialog with live translation…

#include “SystemDialogTrxHlp.hpp”
#include “SystemUiButtonTrxHlp.hpp”

using namespace bb::system;

void MyClass::openDialog() {
    SystemDialog* dialog = new SystemDialog( tr(“Confirm Button”),
        tr(“Cancel Button”) );
    dialog->setTitle( tr(“Dialog Title”) );
    dialog->setBody( tr(“”Dialog Body”) );

    // ---Enable live translation
    new LiveTranslator( “MyClass”, “Dialog Title”, new SystemDialogTrxHlp( dialog ),
        SLOT(setTitle(const QString&)) );
    new LiveTranslator( “MyClass”, “Dialog Body”, new SystemDialogTrxHlp( dialog ),
        SLOT(setBody(const QString&)) );
    new LiveTranslator( “MyClass”, “Confirm Button”,
        new SystemUiButtonTrxHlp( dialog->confirmButton() ),
        SLOT(setLabel(const QString&)) );
    new LiveTranslator( “MyClass”, “Cancel Button”,
        new SystemUiButtonTrxHlp( dialog->cancelButton() ),
        SLOT(setLabel(const QString&)) );

    // ---Now for the magic ingredient
    bool success = QObject::connect( LiveTranslator::localeHandler(),
        SIGNAL(localeOrLanguageChanged()), dialog, SLOT(update()) );

Now for the bad news. See those few lines at the end of the function after the “magic ingredient” comment? Without them live translation of SystemDialog won’t work. Unlike regular UI components, SystemDialog and its brethren don’t automatically repaint themselves or their children when you change one of their attributes. Instead you make all the changes you want and then call or trigger the update() slot. The bad news? That function wasn’t added until the 10.2 API. This means that full live translation of system dialogs is not possible below that API level. I say “full” live translation because even with 10.0 and 10.1 if you leave SystemUiButton labels at their defaults or set them to one of the values that Cascades natively knows how to translate then those labels will be live translated with no additional effort by you. For instance, if you set the SystemDialog confirm button to read “Ok” or “Confirm” then Cascades will automatically add live translation of those words into any language you change your device to and you don’t even need to use the tr() macro when setting them. By carefully choosing your dialog title and body you might be able to get most of the way to live translation even with the lower API levels. Unfortunately, I don’t know of a list of button labels that Cascades can live translate natively so you might need a bit of trial and error. If there is any good news in this it’s that unlike regular screen elements, dialogs are transient entities so the lack of live translation is only evident for a moment. The next time your user opens a dialog, even the same one, it will be correctly translated into the new language.

I have provided the source files for LiveTranslator and some helper classes so all you need to do to get live translation working in your BlackBerry 10 Native C++ code is grab LiveTranslator from github and add it to your project (and any helpers you need too), add a call to LiveTranslator::setLocaleHandler() at the beginning of your main app class constructor and then call new LiveTranslator(…) with the appropriate parameters for each control attribute you want to be live translated. I leave it to the reader to create any additional helper classes they might need. I also created an example app that you can download and run without coding anything yourself. Note that this demo app includes code that live translates a SystemDialog so you must compile it with API 10.2 or better.

The Retranslate class makes it easy to perform live translations from QML, but Cascades does not provide a similar tool for C++ code. A few lightweight classes and extra lines of code bring similar functionality to C++, and best of all you don’t have to rewrite your app to take advantage of it. Just add one line of code for each UI component attribute you want to translate and the LiveTranslate class will take care of the rest.

Cutelyst 0.12.0 is out!

Cutelyst a web framework built with Qt is closer to have it's first stable release, with it becoming 3 years old at the end of the year I'm doing my best to finally iron it to get an API/ABI compromise, this release is full of cool stuff and a bunch of breaks which most of the time just require recompiling.

For the last 2-3 weeks I've been working hard to get most of it unit tested, the Core behavior is now extensively tested with more than 200 tests. This has already proven it's benefits resulting in improved and fixed code.

Continuous integration got broader runs with gcc and clang on both OSX and Linux (Travis) and with MSVC 12 and 14 on Windows (Appveyor), luckily most of the features I wanted where implemented but the compiler is pretty upsetting. Running Cutelyst on Windows would require uwsgi which can be built with MinGW but it's in experimental state, the developer HTTP engine, is not production ready so Windows usefulness is limited at the moment.

One of the 'hypes' of the moment is non-blocking web servers, and this release also fixes this so that uwsgi --async <number_of_requests> is properly handled, of course there is no magic, if you enable this on blocking code the requests will still have to wait your blocking task to finish, but there are many benefits of using this if you have non-blocking code. At the moment once a slot is called to process the request and say you want to do a GET on some webservice you can use the QNetworkAccessManager do your call and create a local QEventLoop so once the QNetworkReply finish() is emitted you continue processing. Hopefully some day QtSql module will have an async API but you can of course create a Thread Queue.

A new plugin called StatusMessage was also introduced which generates an ID which you will use when redirecting to some other page and the message is only displayed once, and doesn't suffer from those flash race conditions.

The upload parser for Content-Type  multipart/form-data got a huge boost in performance as it now uses QByteArrayMatcher to find boundaries, the bigger the upload the more apparent is the change.

Chunked responses also got several fixes and one great improvement which will allow to use it with classes like QXmlStreamWriter by just passing the Response class (which is now a QIODevice) to it's constructor or setDevice(), on the first write the HTTP headers are sent and it will start creating chunks, for some reason this doesn't work when using uwsgi protocol behind Nginx, I still need to dig and maybe disable the chunks markup depending on the protocol used by uwsgi.

A Pagination class is also available to easy the work needed to write pagination, with methods to set the proper LIMIT and OFFSET on Sql queries.

Benchmarks for the TechEmpower framework were written and will be available on Round 14.

Last but not least there is now a QtCreator integration, which allows for creating a new project and Controller classes, but you need to manually copy (or link) the qtcreator directory to ~/.config/QtProject/qtcreator/templates/wizard.


As usual many bug fixes are in.

Help is welcome, you can mail me or hang on #cutelyst at freenode.

Download here.

In Automotive Retailing UX Rubber Hits the CX Road

A popular concept these days is User Experience or UX. Wikipedia defines UX as “the process of enhancing user satisfaction by improving the usability, accessibility and pleasure provided in the interaction between the user and the product.”

A less-used term is Customer Experience or CX. Wikipedia defines that as “the product of an interaction between an organization and a customer over the duration of their relationship. This interaction includes a customer's attraction, awareness, discovery, cultivation, advocacy, and purchase and use of a service.”

Introducing New “Built with Qt” Logo

We are very pleased that you and one million others are using Qt for creating amazing applications and devices for an overwhelming number of different purposes. We are proud when Qt enables developers to create their applications.

In order to make Qt more visible we are now introducing new “Built with Qt” logo.


We have updated the Qt trademark policy to allow the use of the new “Built with Qt” logo in conjunction with the applications and devices using Qt. The logo can be used, for example, in the “about box” or “splash screen” of a Qt based application. The Qt brand guidelines explain how to use the logo correctly and provide the logo in a couple of different formats.

In addition to introducing the new “Built with Qt” logo, we have updated the Qt trademark policy to allow fair use of the Qt logo in many situations, without a separate trademark license. For example, it is allowed to use the Qt logo in electronic marketing material of a product created with Qt as well as in articles about the Qt software or the Qt Project.

Please note that not every use of the Qt trademark is allowed under the fair use. For example, we do not allow the use of Qt trademarks directly in your product names or domain names. Similarly, use of the Qt logo on a book cover still requires a license. The trademark policy provides instructions on how to request permissions to use the Qt logo or other Qt trademarks in different ways than what is allowed in our fair use policy.

The Qt Showroom is continuously seeking more great showcases of Qt usage. If you have created something awesome with Qt, let’s do a showcase together in our Qt Showroom.

You can find the new “Built with Qt” logo and other Qt logos and materials at http://brand.qt.io.

The post Introducing New “Built with Qt” Logo appeared first on Qt Blog.

Release 2.8.5: V-Play Game Network Improvements & New Image Sharing Functionality

Release 2.8.5 is now available for download and as a free update to all V-Play users. This update features improvements to the V-Play Game Network and a host of bug fixes to give you the best V-Play experience.

Update Now!

If you’d like to make cross-platform apps and games but haven’t signed up for V-Play yet, you can download the SDK for free.

Host Images like Facebook

The V-Play Game Network can now be used as a backend for storing images. You can upload images to our Game Network BaaS (Backend-as-a-Service) with the new uploadImage() function.

With this function, you can build your own social media app where users can upload and share their pictures, or create games like Draw Something where the images are stored on our hosted server.

Image Picker

This new Image Picker feature uses the NativeUtils component. The NativeUtils::displayImagePicker() and NativeUtils::displayCameraPicker() methods allow players to choose an image from their device gallery or take a picture with their camera.

These methods give your players advanced personalisation choices when creating any kind of profile.

Native Dialog Improvements

For showing a native dialog with multiple options, the NativeUtils::displayAlertSheet() function is now available. Here is an example how it looks like on iOS:

The new NativeUtils::displayAlertDialog() lets you localize button titles as a replacement for NativeUtils::displayMessageBox(). This replacement component gives you more options when creating dialogs, while retaining native appearance.

NativeUtils::displayTextInput() now lets you set custom or localized button titles. This let’s you create more detailed dialogs, with the latest native appearance to give your users the best UX possible.

V-Play Game Network Improvements

Customizable Profile Pictures

The V-Play Game Network is a cross-platform gaming service that allows players around the world to compare high scores and achievements. It’s available free of charge to all V-Play users and takes less than 10 minutes to integrate into your cross-platform game!

The latest improvement to the Game Network allows players to add a profile image, giving users more personalisation options.


Players can now upload their own profile image in the ProfileView of the V-Play Game Network. They can upload a custom image by taking a picture or choosing an image from the gallery. This new feature works on iOS, Android and Desktop.

For changing the user image in your own views use the following VPlayGameNetwork functions:

Player Location

The V-Play Game Network now allows players to show their location by adding a national flag to their profile. This feature also allows players to customize their V-Play Game Network Profile even further.


This setting reads the locale of a player at app start up but can also be disabled by the player. This feature is enabled for your game by default; you can deactivate it with VPlayGameNetworkView::countryCodeEnabled.

V-Play Game Network Styling Improvements

The latest version of V-Play offers styling improvements to the V-Play Game Network. The following changes will provide a much improved user experience to your players:

  • The VPlayGameNetworkView automatically hides the achievement display button if no achievements are specified.
  • In addition to the back button, clicking the title text in the VPlayGameNetworkView header also allows back navigation.
  • You can make it easier for players to find their friends with highlighting in the overall VPlayGameNetworkView. You can customize the default behaviour with the properties tintFriendPlayerHighlightColor and higlightFriendPlayersWithColorEnabled.
  • Players can now enter Unicode characters as their player name in the VPlayGameNetworkProfileView. This means you and your players can enjoy enhanced localization and personalization as it’s now possible to use a wider character range, from languages such as Arabic and Chinese, for creating usernames.
  • There are also a number of new methods for the V-Play Game Network. These have been added in anticipation of our upcoming V-Play Multiplayer release and can be seen in our change log.

General Improvements

V-Play 2.8.5 is one of the biggest updates of the year!

Besides the improvements to the V-Play Game Network and it’s new BaaS functionality, this update features a wide range of improvements to other areas of the V-Play Engine and V-Play Apps.

How to Update

Test out these new features by following these steps
Step 1

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

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

Step 2

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

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

Sample Launcher-v-play

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

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

The post Release 2.8.5: V-Play Game Network Improvements & New Image Sharing Functionality appeared first on V-Play Engine.

QIcon::fromTheme uses GTK+'s icon cache in Qt 5.7

When you pass a name to QIcon::fromTheme , Qt needs to look up in the different folders in order to know which theme contains the given icon and at which size. This might mean a lot disk access needs to be done only in order to find out if the file exists. Applications such as KMail can have hundreds of icons for each of their menu actions.
In the KF5 port of KMail, 30% of its start-up time was spent loading those icons.

With Qt 5.7, the GTK+ icon cache will be used to speedup the loading of icons.

Freedesktop icon themes

QIcon::fromTheme loads an icon as specified by the Freedesktop Icon Theme Specification and Icon Naming Specification. It specifies the icon themes used by Linux desktops. In summary, an icon theme consists of many folders containing the icons in PNG or SVG format. Each folder contains the icon for a particular size and type. The type might be one of "mimetypes", "actions", "apps". Size are usually all the common sizes. This represents quite a lot of directories per theme. On my computer, Gnome's default theme has 106 folders; the Oxygen theme has 166; Breeze has 56; hicolor has 483.
A theme can also specify one or several fallback themes. Icons which cannot be found in a given theme need to be looked up in the fallback themes until an icon is found. The last resort fallback theme is always "hicolor".

Icon names can contains dashes (-). The dash is used to separate levels of specificity. For example, if the name to look up is "input-mouse-usb", and that this icon does not exist in the theme, "input-mouse" will be looked up instead, until an icon is found.

An icon theme

The nature of these themes and the way icon are looked up implies that the icon engine needs to look at many directories for the existence of files. This is especially true for filenames with many dashes, that might not exist at all. This implies a lot of stat() calls on the hard drive.

Icon Theme Cache

For the above reasons, desktop environments have been using caches to speed up icon loading. In KDE4, KDE's KIconLoader used a shared memory mapped pixmap cache, where the loaded icon data was shared across processes (KPixmapCache). When an application requested an icon of a given size, the cache was queried whether this icon for this size is available. This gave good result at the time in KDE applications. However, this can't be used by pure Qt applications. When running the KDE's Plasma desktop, the platform theme integration plugin can use KIconLoader to load icons which only works when running on Plasma. This caching is anyway not working well with QIcon::fromTheme because we need to know if a QIcon is null or not, and this forces a lookup regardless of the cache.

GTK+ also speeds up the icon lookup using a cache. They have a tool ( gtk-update-icon-cache ) that generates a icon-theme.cache file for each theme. This file contains a hash table for fast lookup to know if an icon is in the theme or not and at which size. The icon cache is system-wide, and usually generated by the distribution's package manager.


Qt can now use GTK+ cache files

The question I asked myself is how to improve the performance of QIcon::fromTheme ? It is clear that we need to use a cache. Should we try to use the KDE pixmap cache? I decided against the KDE pixmap cache because the cache is, in my opinion, at the wrong level. We don't want to cache the icon data, we want to cache a way to get from the icon name to the right file. The cache is also storing some other assets, we might get cache misses more often than we should.

The GTK+ cache is solving the right problem: It is system wide and most Linux distributions already generate it. So I thought, we should just re-use the same cache.

I went ahead and "reverse engineered" the GTK+ icon cache format in order to implement it in Qt. Having GTK+s' source code available to browse clearly helped.

Does that mean that Qt now depends on GTK+?

No, the use of this cache is optional. If the cache is not found or out of date, Qt will ignore the cache and do the full look-ups as before.

How do I make sure the cache is used?

Every time you install an application that adds or removes icons from one of the themes, the cache needs to be updated. Qt looks at the modification time of the directories, if any directory is newer than the cache, the cache will not be used. You need to run gtk-update-icon-cache after installing new icons, but most distributions take care of this for you.

How do I update the cache?

Run this command for every theme:

gtk-update-icon-cache /usr/share/icons/<theme-name> -i -t -f

-i makes it not include the image data into the cache (Qt does not make use of that)


Thank you for reading so far. The summary is that Qt 5.7 will automatically use the GTK+ icon caches. Browse the source of QIconCacheGtkReader if you are interrested.

KDAB, Qt 3D and the Release of Qt 5.7

Some of you may know that Qt 3D is going strong almost entirely due to the work of the KDAB team, led by Dr. Sean Harmer and Paul Lemire. You can read all about its near demise and ultimate rescue here – it’s quite a story, and started with the release of Qt 4.

Now we are approaching another major chapter in the Qt 3D story, as Qt 5.7.0 is released along with a fully supported stable Qt 3D module. Qt 3D offers a high-level facility for 3D graphics, paving the way for making 3D content a first class citizen in Qt applications. This is big news!

Qt 3D allows you to quickly and easily build, render and interact with 3D scenes using either C++ or QML APIs. A custom Qt Quick 2 element called Scene3D is provided, allowing you to easily embed Qt 3D content into a Qt Quick 2 based UI. This allows you to compose 2D and 3D content to create visually stunning user interfaces for a wide range of domains including automotive IVI, medical, and other visualisations like this one.

Qt3D 2.0 has been designed and implemented based on KDAB engineers’ experience of integrating custom 3D renderers into Qt. A lot of the work that has gone into it is not visible, in the form of prototypes, API reviews, testing, debugging, and profiling. This has resulted in over 2500 commits since we moved development into the public Qt git repositories.

Read Sean Harmer’s blog, “Introducing Qt3D”…

You can see more about the Qt3D element of the release here.

Get the full story about this major new release of Qt 5.7 here and in the press release.

KDAB and The Qt Company will continue to improve Qt 3D to add new features, performance improvements, fix bugs and add more documentation and examples.

The post KDAB, Qt 3D and the Release of Qt 5.7 appeared first on KDAB.

Qt 5.7 released

I’m very happy to announce that Qt 5.7 is now available. It’s been only 3 months since we released Qt 5.6, so one might expect a rather small release with Qt 5.7. But apart from the usual bug fixes and performance improvements, we have managed to add a whole bunch of new things to this release.

Updated licensing

Before going into the content and all the cool new features, I should mention the changes to our licensing that have been implemented with Qt 5.7.

Qt has always been available as Free Software, and will continue to be so in the future. Qt is being developed as an open source project, The Qt Company is fully committed to this, and in addition, the agreement with the KDE Free Qt Foundation legally ensures this.

With Qt 5.7, we are slightly adjusting our licensing of the Open Source version to bring it more in line with the philosophy of the Free Software movement. From this version onwards, Qt will not be available under LGPL version 2.1 anymore. Instead, Qt will be licensed under two main licenses: LGPL version 3 (and GPL version 2) for all almost all frameworks and libraries, and GPL version 3 for our tools like e.g. Qt Creator. In addition, we’re open sourcing some formerly closed Qt add-ons and tools under GPL version 3.

Please check our our licensing pages or the licensing FAQ for all details around this. You can also have a look at my blog post from January where I announced this change.

Unifying Qt for Application Development

The license change gives us a unique opportunity to unify our Qt for Application Development offering between the Open Source and Commercial versions. Starting with Qt 5.7, both packages come with exactly the same content.

This means that all the parts of Qt for Application Development that previously have been available only to commercial users are now available in the Open Source package as well.

This includes the following modules:

The only exception is the Qt Quick Compiler where we need some more time to finish the required changes to be able to support this feature in the Open Source Edition.


Qt Virtual Keyboard - Now available for GPL Qt users as well!

Qt Virtual Keyboard – Now available under GPL!


Qt Charts

Qt Charts


It has been possible to use a C++11 compliant compiler together with Qt (and thus use C++11 in your application) for many releases. But Qt itself didn’t make use of it except for some integration points in our API.

With Qt 5.6 being a long-term release that we will support for three years, we have taken the opportunity with Qt 5.7 to start modernizing our own code base. As one of the core strengths of Qt comes from it being a C++ framework, we want to follow the progress of modern C++ more closely.

Starting with Qt 5.7, we will require a C++11 compliant compiler to build and use Qt. This allows us to use many of the new features in Qt itself, and renew our codebase using features such as constexpr, move semantics, range-for and auto. These efforts are well under way and will continue throughout the next versions.


Apart from adding previously commercial-only modules to the Open Source version, we also have quite a bit of new content in Qt 5.7.

Qt 3D

We want to provide you the tools to create the required WOW-effect to amaze your end users. Modern UIs in many areas require the integration of 3D graphics, or even creating the whole user experience in three dimensions. In past years we’ve been improving our developer offering to make it easier for you to add this dimension into your UIs. With Qt 5.7, we are bringing in the Qt 3D module. This module has been available as a Technology Preview for two releases now, and I’m happy to announce that it has now reached the state where it is becoming a fully supported member of the Qt family!

Qt 3D complements the 3D GUI offering of Qt consisting of integration to OpenGL, Qt Canvas 3D, and Qt Data Visualization modules. Qt 3D provides you with a 3D engine, that comes with both C++ and QML APIs. It makes it a lot easier to embed and handle 3D content within Qt Applications. In general, Qt 3D is much more than just a renderer, it serves as an extensible 3D framework for all kind of simulations. The architecture and most of the development on Qt 3D over the past years has been done by our partner KDAB, a huge thanks goes to them for their work. For a proper introduction, please see the guest blog post from Sean Harmer from KDAB.

Qt Quick Controls 2

Qt 5.7 also comes with a fully supported version of our new Qt Quick Controls, the library of QML-based UI controls. Qt Quick Controls 1 were targeted at the desktop, and came with all the bells and whistles required for desktop applications. This implied an overhead that often made them too slow for usage on embedded devices.

Qt Quick Controls 2 solve these issues. They have been built from the ground up with performance and memory consumption in mind. So while they are fully usable on the desktop, they have slightly more limited functionality and e.g. don’t come with native styling integration. But they are vastly faster, and use a lot less memory than the old controls, making them ideal for many embedded and mobile solutions. Qt Quick Controls 1 are still part of the offering and a suitable API for desktop development. For instance, the Qt Quick Layouts work nicely with both of the control sets.


Architecturally, Qt Quick Controls are based on templates that allow you to create your completely own set of controls ground-up. They also come with a flexible system that allows the rapid creation of custom styles and user experiences. In addition, the existing controls come with three predefined styles:

  • Default style – a simple and minimal all-around style that offers the maximum performance
  • Material style – a style based on the Google Material Design Guidelines
  • Universal style – a style based on the Microsoft Universal Design Guidelines

For a good overview, more details and a teaser video, please see the blog post from J-P Nurmi.

New functionality in existing modules

A lot of new functionality has been added to existing modules, and this blog can’t cover them all. Some of the highlights are:

Qt Core

  • Qt uses poll() instead of select() in it’s event loop allowing for more than 1024 file descriptors
  • Qt now uses std::atomic for it’s atomic classes

Qt Gui

  • NEON optimizations for image scaling in Qt Gui
  • Optimized the OpenGL function wrappers in Qt for size and speed

Qt QML and Quick

  • JIT support for WinRT, and 64bit ARM platforms in Qt QML, leading to much better QML performance on these platforms
  • The debugger now supports debugging multiple QJSEngine instances at the same time
  • Improved profiler and inspector integration

Qt WebEngine

  • Qt WebEngine is now based on Chromium 49 and can now print to PDF
  • Support for DRM-protected HTML5 video in WebEngine


  • Support for Android

For all the details, please have a look at our New Features page and the Changes file for Qt 5.7.

Qt for Device Creation

Also Qt for Device creation has received an update and does now ship with Qt 5.7. In this release, we added out of the box support for a set of new hardware:

  • The NVIDIA DRIVE CX boards (Tegra X1, 64 bit ARM)
  • The Rasberry Pi 3 (32 bit mode)
  • i.MX7 based devices (without GPU, uses the Linux framebuffer and the Qt Quick 2D renderer)

Microsoft Windows is now a fully supported as a host platform for developing for embedded Linux. While Qt for Device Creation 5.7 does no longer support Windows Embedded, we now have full support for QNX, including pre-built binaries.

To read more about changes in Qt for Device Creation, please see the separate blog post.

Qt Creator 4.0

Qt 5.7 ships with Qt Creator 4.0, more precisely with the new Qt Creator 4.0.2 version. Qt Creator 4.0 is a full development environment for all desktop, mobile and embedded development and now with version 4, we’ve especially emphasized the designer-developer workflow with the integration of Qt Quick Designer visual layout editor and the new Qt Quick Controls 2. Together, they provide a really nice way to rapidly create touch-based UIs for your embedded and mobile applications. Check out the separate video about the workflow from this blog post.

Qt Creator 4.0 also comes with a set of nice new features, such as Clang integration and extended QML profiler, please find the details from the Qt Creator 4.0 blog post. For the updates regarding Qt 4.0.2, please see the change files.

New Technology previews

In addition, Qt 5.7 also adds a couple of new modules as Technology Previews.

The first one is the Qt Wayland Compositor. The module makes it very easy to create your own Wayland Compositor. This is especially useful for embedded devices that require multi process support. The module has existed as unsupported technology for some time, but has had issues in both the API and implementation. With Qt 5.7, we’ve invested a lot of time and effort to clean up implementation and stabilize the API. It now comes with a full QML API and an improved C++ API with a lot of convenience. We also added a convenience API to create Wayland extensions and use them from both QML and C++. You can read more about it from the blog post from Paul.

The next new module is Qt SCXML. It’s a completely new module that makes it very easy to integrate SCXML based state machines into Qt. It builds directly on top of the Qt Statemachine framework and extends it with with both a SCXML to C++ compiler and a runtime that allows loading SCXML based state machines.

Qt Gamepad is another nice small addition. It makes it possible to ingrate gamepad support into both C++ and QML applications. It currently supports Windows, Linux, Android and iOS.

With Qt for Device Creation, we’re also introducing the first preview of Qt-based Over-the-Air (OTA) updates mechanism. For an overview of this crucial IoT-technology, please see the blog post from Gatis.

Finally, Qt 5.7 also includes a technology preview of the new Qt SerialBus module that allows you to use Qt APIs for device bus communications and protocols. It’s a generic API, but with this version it includes implementations for CAN and Modbus.

Go and get it

Finally, I’d like to give my thanks to everybody who has helped create this release. Again, a special thanks goes to KDAB for its tremendous work on Qt 3D.

You can get Qt 5.7 from your Qt Account or the download page on qt.io.

For an overview of the Qt 5.7, you can take a look at the release page, or for more details check the change files and known issues.

Enjoy the release and have a great, Qt-filled summer!

The post Qt 5.7 released appeared first on Qt Blog.

Qt 5.7 for Device Creation

With the Qt 5.7, we’ve improved a lot of things inside our offering for embedded device creation, the Qt for Device Creation product. Here’s a brief overview on what has happened on this side, in addition to the enhancements to the other Qt 5.7 libraries many of which also facilitate the embedded development like for instance the new Qt Quick Controls 2.0. One of the biggest visible item inside our device creation offering is the Boot to Qt software stack, but in addition to just providing pre-built images, we’ve made our approach as customizable and easily installable as possible by harmonizing our work with the tooling from the Yocto Project.

Working with the Yocto Project

The Yocto Project is an open source collaboration project that provides templates, tools and methods to help you create custom Linux-based systems for embedded products regardless of the hardware architecture. We have leveraged Yocto internally for a long time and for the past year we have been working together with meta-qt5, the open source Yocto compatible meta layer dedicated for building Qt modules for your embedded devices. We are working upstream within the Yocto Project and in addition we have a mirror of the meta-qt5 layer within the Qt Project to ensure it always works with the latest Qt version. The layer was also recently updated to provide recipes for the previously commercial modules (Qt Virtual Keyboard, Qt Charts and Qt Data Visualization), which are now also available with a GPL license for open source users of Qt 5.7.0. In addition, we in Qt are providing our own distro layer called meta-boot2qt. It is a glue which combines the vendor specific BSP layers and meta-qt5 into one package. In meta-boot2qt layer there are defined the stable and tested versions of the different software components so that it is you can kickstart you embedded project with your favorite hardware.

In all, our target has been to utilize the standardized Yocto Project mechanisms so that our offering is as compatible with Yocto Project as possible. With Qt 5.7, the pieces are nicely in place.

New Device Images

We’ve also updated the hardware selection for our pre-built software images with two new additions:

For these, and the other common development boards, we provide the pre-built image with our SDK installer. You can flash the device with the image and immediately get started with embedded development.

Windows Host Support

Few months ago with Qt 5.6, we introduced the possibility of using Windows host computer for embedded Linux development and deployment as a tech preview. With Qt 5.7 we’ve polished the solution even further and this is now fully supported.



Over-the-Air Updates (OTA)

A new piece of technology that we’re introducing with Qt 5.7 for device creation is an OSTree-based solution for Over-the-Air software updates for the whole software stack. For the full story, please take a look at the separate blog post.

Graphics Updates

On the graphics side, we’ve added new configuration specs for NVIDIA DRIVE CX and NXP i.MX7. Laszlo wrote a full story around these in the blog last week, so read more from his post.

Qt Device Utilities

One part of our embedded offering is the Qt Device Utilities module that allows users to manipulate easily various embedded device settings via simple QML APIs.

Here’s short overview of the different settings the new Qt Device Utilities has to offer:

  • QtDeviceUtilities.NetworkSettings
    • Network settings utilizes Connman backend and exposes settings for discovering, configuring and connecting to ethernet networks and wifi access points.
  • QtDeviceUtilities.DisplaySettings
    • Display settings allows user to set display’s brightness level and change the physical screen size.
  • QtDeviceUtilities.TimeDateSettings
    • Time & Date settings provides functions to adjust system timezone, date and time settings either manually or automatically using NTP (Network Time Protocol)
  • QtDeviceUtilities.LocaleSettings
    • Locale settings allows to change current system locale including language and regional format
  • QtDeviceUtilities.LocalDeviceSettings
    • Provides utility functions for controlling an embedded device shutdown and reboot
  • QtDeviceUtilities.BluetoothSettings
    • Bluetooth settings allows to discover and connect to various bluetooth devices utilising Bluez backend (http://www.bluez.org/)
  • QtDeviceUtilities.SettingsUI
    • Settings UI QML component to display settings UI made with Qt Quick Controls 2

If you want to take a look at the new settings, we’ve updated the default demo launcher for the Boot to Qt image to use the new QtDeviceUtilities.SettingsUI plugin:



New display settings under Boot to Qt demo launcher, using the new Utilities module and Qt Quick Controls 2

Some of the new settings under Boot to Qt demo launcher, using the new Utilities module and Qt Quick Controls 2


So, that’s pretty much it. Hope you enjoy Qt 5.7 for Device Creation!

For the customers with Qt for Device Creation license, you can find Qt for Device Creation components using your online installer. If you do not yet have Qt for Device Creation and want to try it out, please contact us to request an evaluation of Qt for Device Creation.

The post Qt 5.7 for Device Creation appeared first on Qt Blog.

Introducing Qt 3D

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

Introducing Qt 3D

One of the major new features in Qt 5.7.0 is the fully supported release of a stable Qt 3D module! Although Qt has long offered facilities for taking advantage of accelerated graphics and integrating custom OpenGL rendering in Qt-based applications, it has not provided a high-level facility for 3D graphics. Qt 3D now provides this and paves the way for making 3D content a first class citizen in Qt applications.

Qt 3D allows you to quickly and easily build, render and interact with 3D scenes using either C++ or QML APIs. We also provide a custom Qt Quick 2 element called Scene3D that allows you to trivially embed Qt 3D content into a Qt Quick 2 based UI. This allows for the composition of 2D and 3D content to create visually stunning user interfaces for a wide range of domains including automotive IVI, medical, and other visualisations.

Features of Qt 3D

Based on the experience and lessons learned at KDAB helping many of our customers integrate 3D content into their applications Qt 3D has been architected to be more than just a 3D renderer. Qt 3D is a framework for soft realtime simulations – although rendering is still a very important part of this. What does this mean in practice? Well, it means that if Qt 3D doesn’t quite fit your needs, then you can freely extend it to support your use cases. Unlike traditional OOP, Qt 3D is built upon an Entity Component System (ECS) which favours aggregation over deep and wide inheritance hierarchies (see this Overview of Qt 3D for more information).

The ECS architecture also provides a way for us to continue to develop Qt 3D in the future without having to make restrictive assumptions now. As an example, support for collision detection and rigid-body physics simulations can be added in without impacting the renderer at all. We have taken care to ensure that the core architecture of Qt 3D as well as the renderer are as generic as possible.

The Qt3DCore library provides the basic infrastructure that the rest of Qt 3D builds upon. It is a lightweight library but provides a very scalable framework that takes advantage of today’s and tomorrow’s many core hardware. If you create your own aspects for Qt 3D, the core provides you with a very nice task-based threading framework to allow your jobs to be distributed across a thread pool with dependencies between jobs taken care of. Qt 3D’s architecture keeps the main thread as free of heavy work as possible by shifting such work to the thread pool. The Qt3DCore library makes it easy to communicate between the frontend and backend objects.

The Qt3DRender module is a high-level interface to hardware accelerated graphics. At present Qt 3D uses an OpenGL backend but we have left the door open to be able to support more modern APIs such as Vulkan, Metal and DirectX 12 in the future. Qt 3D already supports the vast majority of the OpenGL feature set including compressed textures, instanced rendering, and all shader stages – yes, you can now use OpenGL compute shaders with Qt 3D!

One of the key features of Qt 3D’s renderer is the frame graph concept. The frame graph is a way to specify how a 3D scene is rendered. Traditionally this would be hard-coded in low-level C++ code that implements logic around which groups objects are rendered, in what order, using which specific cameras, what the current render target is etc. We wanted to avoid users having to provide such low level code in order to control the rendering algorithm. The frame graph does this by allowing the developer to specify data that describes the rendering algorithm which Qt 3D then translates into the low level code. The approach is data driven which means that the complete rendering approach can be dynamically changed at run-time and without touching any C++ code at all. For more information on the frame graph concept please take a look at this KDAB blog post.

The Qt3DInput module adds support to Qt 3D for reacting to inputs from the traditional mouse and keyboard devices and also allows extension to support other custom input devices such as 3D mice, gamepads, joysticks and anything supported by the QtGamepad module. Qt3DInput also allows you to map multiple physical devices into logical devices and to get analog axis values out of them for use in property bindings or your own custom C++ code.

One thing you will not find in the above libraries is high-level utilities. This is for two reasons. The first is that we want to keep the renderer and other core facilities as generic as possible. Providing a collection of materials based on the traditional Phong lighting model there would bake in some assumptions that we would then need to live with until Qt 6. The second reason is that some of these higher level facilities depend upon more than one Qt 3D library. For example, the camera controllers depend upon multiple Qt 3D libraries libraries for their implementation.

Whilst the above libraries are all stable, we do still have one Qt 3D library marked as unstable for now. The Qt3DExtras library provides a collection of basic geometries, materials and other utilities and integration points. Whilst we do not expect the facilities provided by Qt3DExtras to change much, we did not yet feel comfortable with freezing the API of these higher level helpers. This compromise makes Qt 3D useable out of the box but on the understanding that the API of these classes may evolve a little in the future. Of course you are also free to write your own specialised set of geometries and materials for your own use cases. We will also continue to develop such higher level primitives and package them up into coherent libraries. For example, we may well decide to provide a set of Physics Based Rendering (PBR) materials as seen in the Qt Automotive Suite, or perhaps a set of classes for generating and manipulating geometric shapes.


The Future of Qt 3D

Qt 3D as released with Qt 5.7.0 is just the beginning. KDAB and The Qt Company recently held a Qt 3D planning session in Oulu. Some of the prominent features that we have planned for future releases include:

  • Collision detection
  • Key-frame and morph target animation system
  • Rigid-body physics simulation
  • Qt Quick 2 within Qt 3D
  • Use QPainter to paint on textures
  • PBR materials
  • Dynamic materials
  • Support for more input devices
  • Build time/design time tooling for asset conditioning
  • Profiling and debugging tooling – stand alone and as part of GammaRay


In addition to the above features, there is a proof of concept Qt 3D Scene Editor available for you to try. This editor allows you to graphically compose a 3D scene and export it to QML.


We are also working on a Qt 3d profiler and debugging tool that allows you to see details of the jobs executed on the Qt 3D thread pool along with their timings and to issue commands to introspect the internal Qt 3D engine state.


With this initial release of Qt 3D, we now have a powerful framework and foundation on which to build UIs of the future. Please do take Qt 3D for a spin and let us know what you think. If you are interested in getting involved with writing code or shaders, documentation, examples, producing assets, helping with JIRA, then please do get in touch via the development mailing lists or on IRC at #qt-3d.

The post Introducing Qt 3D appeared first on Qt Blog.

Beautiful But Dangerous: Cinematic Interfaces in the Real World

When I was an engineering student at WPI, one of the non-technical classes I took required us to read Mary Shelley’s classic book Frankenstein.  As a young geek, I had already read it, but not with the intent of analyzing the very important theme running through it that all technologists should consider: just because you can do something doesn’t mean you should do something.

Victor Frankenstein was so obsessed with conquering death that he didn’t stop to think through the repercussions, and the results…. Well, if you don’t know, read the book.

Trojita 0.7 with GPG encryption is available

Trojitá, a fast Qt IMAP e-mail client, has a shiny new release. A highlight of the 0.7 version is support for OpenPGP ("GPG") and S/MIME ("X.509") encryption -- in a read-only mode for now. Here's a short summary of the most important changes:

  • Verification of OpenPGP/GPG/S-MIME/CMS/X.509 signatures and support for decryption of these messages
  • IMAP, MIME, SMTP and general bugfixes
  • GUI tweaks and usability improvements
  • Zooming of e-mail content and improvements for vision-impaired users
  • New set of icons matching the Breeze theme
  • Reworked e-mail header display
  • This release now needs Qt 5 (5.2 or newer, 5.6 is recommended)

As usual, the code is available in our git as a "v0.7" tag. You can also download a tarball (GPG signature). Prebuilt binaries for multiple distributions are available via the OBS, and so is a Windows installer.

The Trojitá developers

An Introduction to Python Part 2

Continuing our three-part series on the Python programming language, in this post we'll look at more of the core language features.

File I/O

Python provides a number of functions for file input and output, similar to what is provided in standard libraries for languages like C and C++. Shown below are examples of some of the more commonly used functions to give you a flavor for what is offered. Most of these should be self-explanatory. The last function may not be as obvious -- it prompts the user and reads from standard input.

QtCon – Register now!

Berlin, September 1-4

The program is published and registration is open! Don’t miss the biggest Qt Event in Europe in 2016 – QtCon.

Be an Early Bird and sign up for QtCon 2016 before July 1st! A unique opportunity to meet and learn from 5 different communities, all pioneers at the top of their field: KDAB, KDE, Qt Contributors, FSFE and VideoLAN.

Sign up for KDAB Training on September 1st and take your pick from 8 superb choices. Top training from the experts at just €250 a day.


The post QtCon – Register now! appeared first on KDAB.

New Compositor API for Qt Wayland

As part of the forthcoming Qt 5.7, we are happy to be releasing a tech preview of the new Qt Wayland Compositor API. In this post, I’ll give you an overview of the functionality along with few examples on how to create your own compositors with it.

Wayland is a light-weight display server protocol, designed to replace the X Window System. It is particularly relevant for embedded and mobile systems. Wayland support in Qt makes it possible to split your UI into different processes, increasing robustness and reliability. The compositor API allows you to create a truly custom UI for the display server. You can precisely control how to display information from the other processes, and also add your own GUI elements.

Qt Wayland has included a compositor API since the beginning, but this API has never been officially released. Now we have rewritten the API, making it more powerful and much easier to use.

Here’s a snapshot of a demo that we showed at Embedded World: it is a compositor containing a launcher and a tiling window manager, written purely in QML.


We will keep source and binary compatibility for all the 5.7.x patch releases, but since this is a tech preview, we will be adding non-compatible improvements to the API before the final release. The Qt Wayland Compositor API is actively developed in the dev branch of the Qt git repository.

The Qt Wayland Compositor tech preview will be included in the Qt for Device Creation packages. It is not part of the Qt for Application Development binary packages, but when compiling Qt from source, it is built by default, as long as Wayland 1.6 is installed.

What is new?

  • It is now possible to write an entire compositor in pure QML.
  • Improved API: Easier to understand, less code to write – both QML and C++ APIs
  • Completely reworked extension support: Extensions can be added with just a few lines of QML, and there’s a powerful, easy-to-use C++ API for writing your own extensions.
  • Multi-screen support
  • XDG-Shell support: Accept connections from non-Qt clients.
  • And finally, a change that is not visible in the API, but should make our lives easier as developers: We have streamlined the implementation and Qt Wayland now follows the standard Qt PIMPL(Q_DECLARE_PRIVATE) pattern

Take a look at the API documentation for more details.


Here is a complete, fully functional (but minimalistic) compositor, written purely in QML:

import QtQuick 2.6
import QtQuick.Window 2.2
import QtWayland.Compositor 1.0

WaylandCompositor {
    id: wlcompositor
    // The output defines the screen.
    WaylandOutput {
        compositor: wlcompositor
        window: Window {
            visible: true
            WaylandMouseTracker {
                anchors.fill: parent
                enableWSCursor: true
                Rectangle {
                    id: surfaceArea
                    color: "#1337af"
                    anchors.fill: parent
    // The chrome defines the window look and behavior.
    // Here we use the built-in ShellSurfaceItem.
    Component { 
        id: chromeComponent
        ShellSurfaceItem {
            onSurfaceDestroyed: destroy()
    // Extensions are additions to the core Wayland 
    // protocol. We choose to support two different
    // shells (window management protocols). When the
    // client creates a new window, we instantiate a
    // chromeComponent on the output.
    extensions: [
        WlShell { 
                chromeComponent.createObject(surfaceArea, { "shellSurface": shellSurface } );
        XdgShell {
                chromeComponent.createObject(surfaceArea, { "shellSurface": xdgSurface } );

This is a stripped down version of the pure-qml example from the tech preview. And it really is a complete compositor: if you have built the tech preview, you can copy the text above, save it to a file, and run it through qmlscene:

These are the commands I used to create the scene above:

./bin/qmlscene foo.qml &
./examples/widgets/widgets/wiggly/wiggly -platform wayland &
weston-terminal &
./examples/opengl/qopenglwindow/qopenglwindow -platform wayland &

The Qt Wayland Compositor API can of course also be used for the desktop. The Grefsen compositor (https://github.com/ec1oud/grefsen) started out as a hackathon project here at the Qt Company, and Shawn has continued developing it afterwards:



The C++ API is a little bit more verbose. The minimal-cpp example included in the tech preview clocks in at 195 lines, excluding comments and whitespace. That does not get you mouse or keyboard input. The qwindow-compositor example is currently 743 lines, implementing window move/resize, drag and drop, popup support, and mouse cursors.

This complexity gives you the opportunity to define completely new interaction models. We found the time to port everyone’s favourite compositor to the new API:


This is perhaps not the best introduction to writing a compositor with Qt, but the code is available:
git clone https://github.com/paulolav/mazecompositor.git

What remains to be done?

The main parts of the API are finished, but we expect some adjustments based on feedback from the tech preview.

There are still some known issues, detailed in QTBUG-48646 and on our Trello board.

The main unresolved API question is input handling.

How you can help

Try it out! Read the documentation, run the examples, play around with it, try it in your own projects, and give us feedback on anything that can be improved. You can find us on #qt-lighthouse on Freenode.

The post New Compositor API for Qt Wayland appeared first on Qt Blog.

qutebrowser v0.7.0 released

I'm happy to annouce the release of qutebrowser v0.7.0!

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

As usual the source release is available, binary releases (Windows as usual, and now also a standalone OS X .app/.dmg and a Debian .deb) will follow ASAP (but might be Monday until everything is taken care of).

This is a really exciting release! It comes with fixes for a few long-standing bugs (like being able to use :hint spawn with flags or sharing of cookies between tabs with private browsing) and includes many new features (like marks to remember the scroll position).

It also comes with a greatly improved hint and history implementation: Hints now work more reliably in some corner cases, and gained a few new features and other bugfixes. The history completion now contains titles and handles redirects.

And there's a lot more than that - see the full changelog:


  • New :edit-url command to edit the URL in an external editor.

  • New network -> custom-headers setting to send custom headers with every request.

  • New {url:pretty} commandline replacement which gets replaced by the decoded URL.

  • New marks to remember a scroll position:
    • New :jump-mark command to jump to a mark, bound to '
    • New :set-mark command to set a mark, bound to ` (backtick)
    • The ' mark gets set when moving away (hinting link with anchor, searching, etc.) so you can move back with ''
  • New --force-color argument to force colored logging even if stdout is not a terminal

  • New :messages command to show error messages

  • New pop-up showing possible keybinding when the first key of a keychain is pressed. This can be turned off using :set ui keyhint-blacklist *.

  • New hints -> auto-follow-timeout setting to ignore keypresses after following a hint when filtering in number mode.

  • New :history-clear command to clear the entire history

  • New hints -> find-implementation to select which implementation (JS/Python) should be used to find hints on a page. The javascript implementation is better, but slower.


  • qutebrowser got a new (slightly updated) logo
  • :tab-focus can now take a negative index to focus the nth tab counted from the right.
  • :yank can now yank the pretty/decoded URL by adding --pretty
  • :navigate now clears the URL fragment
  • :completion-item-del (Ctrl-D) can now be used in :buffer completion to close a tab
  • Counts can now be used with special keybindings (e.g. with modifiers)
  • Various SSL ciphers are now disabled by default. With recent Qt/OpenSSL versions those already all are disabled, but with older versions they might not be.
  • Show favicons as window icon with tabs-are-windows set.
  • :bind <key> without a command now shows the existing binding
  • The optional colorlog dependency got removed, as qutebrowser now displays colored logs without it.
  • URLs are now shown decoded when hovering.
  • Keybindings are now shown in the command completion
  • Improved behavior when pasting multiple lines
  • Rapid hints can now also be used for the normal hint target, which can be useful with javascript click handlers or checkboxes which don't actually open a new page.
  • :zoom-in or :zoom-out (+/-) with a too large count now zooms to the smallest/largest zoom instead of doing nothing.
  • The commandline now accepts partially typed commands if they're unique.
  • Number hints are now kept filtered after following a hint in rapid mode.
  • Number hints are now renumbered after filtering
  • Number hints can now be filtered with multiple space-separated search terms
  • hints -> scatter is now ignored for number hints
  • Better history implementation which also stores titles. As a consequence, URLs which redirect to another URL are now added to the history too, marked with a -r suffix to the timestamp field.


  • Fixed using :hint links spawn with flags - you can now use things like the -v argument for :spawn or pass flags to the spawned commands.
  • Various fixes for hinting corner-cases where following a link didn't work or the hint was drawn at the wrong position.
  • Fixed crash when downloading from an URL with SSL errors
  • Close file handles correctly when a download failed
  • Fixed crash when using ;Y (:hint links yank-primary) on a system without primary selection
  • Don't display quit confirmation with finished downloads
  • Fixed updating the tab index in the statusbar when opening a background tab
  • Fixed a crash when entering :-- in the commandline
  • Fixed :debug-console with PyQt 5.6
  • Fixed qutebrowser not starting when sys.stderr is None
  • Fixed crash when cancelling a download which belongs to a MHTML download
  • Fixed rebinding of keybindings being case-sensitive
  • Fix for tab indicators getting lost when moving tabs
  • Fixed handling of backspace in number hinting mode
  • Fixed FileNotFoundError when starting in some cases on old Qt versions
  • Fixed sharing of cookies between tabs when private-browsing is enabled
  • Toggling values with :set now uses lower-case values
  • Hints now work with (non-standard) links with spaces around the URL
  • Strip off trailing spaces for history entries with no title

Since v0.6.0, the following people have contributed to qutebrowser:

  • Ryan Roden-Corrent
  • Daniel Schadt
  • Jakub Klinkovsk
  • Panagiotis Ktistakis
  • Corentin Jul
  • Felix Van der Jeugt
  • Tarcisio Fedrizzi
  • Liam BEGUIN
  • Jimmy
  • kanikaa1234
  • Tomasz Kramkowski
  • Philipp Hansch
  • Nick Ginther
  • Fritz Reichwald
  • haitaka
  • Ismail
  • adam
  • Stefan Tatschner
  • Samuel Loury
  • Jan Verbeek
  • oniondreams
  • Xitian9
  • Noah Huesser
  • Johannes Martinsson
  • Jay Kamat
  • Error 800
  • Alexey Glushko

Thank you!

Qt Quick Controls 2.0 – a new beginning!

Qt Quick Controls 2.0 has come a long way since its first technology preview release with Qt 5.6. It provides a more mature set of controls, which are not based on Qt Quick Controls 1 and are redesigned from scratch to gain a significant performance boost. Enough has already been said about the bottlenecks with Qt Quick Controls 1 and its complicated design to support a whole variety of use cases, so let’s not dig into it again. But if you are interested, refer to these blog posts:

The new version 2.0 of Qt Quick Controls enables designing lighter user interfaces, which is a key requirement these days for developing applications that behave well even on environments with limited resources. The APIs provided by the new controls take a more declarative approach, for instance, using attached properties extensively. They also provide more advanced and low-level features such as inheriting font, locale, and style. Such features were supported by Qt Widgets since day one, but they never existed in Qt Quick Controls 1.

Qt Quick Controls 2 is shipped with three styles: Default, Material, and Universal. The latter two are based on Google’s Material and Microsoft’s Universal styles, which are platform- and device-agnostic designs with publicly available specifications. They fit well to the notion, “one template, one behavior, multiple design languages / styles”, that Qt Quick Controls 2 builds upon. There are no native styles in Qt Quick Controls 2 – all styles are cross-platform and look the same on all platforms. Here is a preview of these styles in action:


You could style a single control in your application to give it a different look than what is offered by these styles. In fact, the new controls also enable creating complete style-sets that could be applied to all or several instances of controls used in your application. See the Qt Quick Controls 2 customization instructions for more details.

The following is a video of an application that simulates a coffee machine use case with Qt Quick Controls 2.

With the Qt 5.7 release, the new controls graduates to a fully supported module, after being in the works for almost 1.5 years. Try the Qt 5.7.0 RC to explore the new possibilities with Qt Quick Controls 2!

The post Qt Quick Controls 2.0 – a new beginning! appeared first on Qt Blog.

Branding by UX – Announcing Qt Automotive Suite



Pelagicore is proud to announce the launch of Qt Automotive Suite, a product jointly developed and marketed together with The Qt Company and KDAB.


As car makers turn their cars into digital companions, taking ownership of the digital UX has become a critical stepping stone.


With Qt Automotive Suite, we now enable creative minds to work on the edge of what is technically possible and deliver a UX that is quite simply stunning: modern software architecture, consistent and elegant APIs, tooling for designers and developers – all the way from concept to production.


Read more here: http://blog.qt.io/blog/2016/06/08/announcing-the-qt-automotive-suite/

Announcing The Qt Automotive Suite


Today we announce the launch of the first generation of the Qt Automotive Suite.

The idea for the Qt Automotive Suite was born when The Qt Company, Pelagicore and KDAB sat down and shared their experiences of projects using Qt for In-vehicle Infotainment (IVI). With cumulative experience from over 20 automotive projects it was noted how Qt is really well suited to the needs of building IVIs and Instrument Clusters, that there were already millions of vehicles on the road with Qt inside, and that there were a lot of ongoing projects. There was though a feeling that things could be even better, that there were still a few things holding back the industry, contributing to the sense that shipped IVI systems could be built faster, cheaper and with a higher quality.

One observation was that additional infrastructure components and tooling were being created. While it is great to see software being built on top of Qt, from an industry perspective it is inefficient with duplication of work, little reuse across projects and engineering resources being used to maintain them rather than focusing on differentiating features. So we’ve added some of these components to the Qt Automotive Suite and will continue to add more over time.

Another observation was that industry practices had been slow to change from when IVI was simply a radio with a two-line display. Then, writing a specification and outsourcing the implementation worked well. Now there are multiple screens in the car that represent the digital UX and allow the user to physically interact with the brand. This digital UX needs to be perfectly integrated with the entire interior design making it almost impossible to perfect a consistent user experience first time in the design house: some refinement is inevitable when the HMI is tested in-vehicle and unanticipated usability problems are found. We are seeing changes in the industry with OEMs taking control of not just the HMI design but also its development. The tools we are adding will make it faster to try out UI changes and to deploy to the target. More iterations mean a more refined UX and a better experience for the end customer.

Automotive Suite Architecture

What is the Automotive Suite? A picture is better than a thousand words so here’s what it looks like with the parts outlined in red specific to the Automotive Suite.


All the added pieces were carefully selected with the goal to make it faster to build better in-vehicle experiences. Let’s now describe some of the components in the diagram above and why we added them.

Qt for Device Creation

The Qt Automotive Suite inherits all the good parts of Qt for Device Creation. This include the QML language for building modern user interfaces, Wayland support with the Qt Wayland Compositor, Qt WebEngine based on Chromium, remote deploy and debugging directly to your target board and a comprehensive class library including multimedia and networking to make writing application logic faster and more fun.

The Application Manager and Compositor

IVI systems are getting more complex and building a complex UI with a single application is becoming unwieldy and fragile. The Application Manager and Compositor bring a modern multi-process architecture to Linux in the car. Separating the HMI into different functional units allows independent teams to develop and test both separately and simultaneously, reducing project risk and shortening development time. 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.

The Qt Wayland Compositor, which debuts as a technical preview in Qt 5.7, is integrated with the Application Manager which can be used to take care of a virtual keyboard and notifications as well as compositing the displays from multiple applications. How these different displays are composited is completely up to the HMI design team, with the QML language being used to define the layout and behavior of output from each application.

The Application Manager handles the complete lifecycle of an application. It validates the installation package and can handle API access permissions. If the Application Manager determines that the system is running low on resources, for example memory, it can shut down idle applications.

Application launch time is fast due to pre-forking a process to run the application.


We advocate splitting the HMI into applications. There might be one for media playback, another for phone call handling and another for display vehicle status. These have to talk to the middleware so we’ve build a set of cross-platform Qt APIs called QtIVI to abstract these from the underlying middleware.

QtIVI – Automotive APIs

The QtIVI APIs introduces a level of standardization within the Qt ecosystem for how to access automotive-specific APIs. The goal is to promote reuse: 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.

The QtIVI APIs follow a pattern to provide common, but extendable, Qt interfaces integrating to the various platform middleware components used by the various OEMs. This means that the same function is exposed through the same interface, even if the implementation is completely different. The core functionality can also include a channel to the Application Manager to check to see whether the application calling a particular component has permission to use the API.

As and where it makes sense, we will provide backends for GENIVI, QNX and AGL. In the future there will also be backends that work with the desktop device emulator, described next.

Device emulation

One thing we’ve found in automotive programs is that there are never enough hardware units to go around and they are never available early enough in the development cycle. Qt for Device Creation includes an emulator for testing your application on the desktop so we will be extending it to support all the QtIVI APIs. This will allow the inputs to be simulated or even scripted to do what you want so the whole system can be tested on the bench. Not only will this be great for developers, it will also be great for QA, allowing input values to be scripted and even out-of-range value to be tested.

QML Live – Update the UI on a Live System

Getting the UI correct is typically an iterative cycle. Do a design, implement it and see how it looks. The faster a design can be tested, the more iterations and the better the end result. Usually, testing a new UI design involves a compile, link and flashing of the device. With QML Live a change to a QML file can be seen running on a live system as soon as the Save button is hit. This makes tuning color schemes, fonts, and animations on target display just so much more productive.

Deploy to Target & Debugging from Qt Creator

Qt for Device Creation is our product for embedded systems. A key feature is being able to build and download an app to the target device and optionally launch a debugger all with one click from within the Qt Creator IDE. The Automotive Suite includes this functionality which removes the lengthy device flashing stage which makes developers much more productive.

Profiling & Diagnostics

Qt Creator already provides remote debugging tools. It also provides profilers to see how long your QML code is taking to execute which is critical for ensuring smooth 60fps operation and instant start-up. The Qt Automotive Suite deeply integrates an additional tool called GammaRay into 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.

Each automotive program and platform is different and great tools that increase productivity need to be extensible and tailored to a specific context. For that reason GammaRay also provides building blocks for the creation of visualization and diagnosis of proprietary frameworks, specialized hardware or protocols, custom controls or third party components. So if there is a specific aspect of the system you routinely need to look at in depth, GammaRay can be extended to do that in a way that integrates seamlessly with the existing development tools.

SDK Creation

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 for discussions on engineering and product direction.


The Qt Automotive Suite v1.0 is timed for release towards the end of June, shortly after the availability of Qt 5.7. It will support any Linux and work just fine and for anyone wanting to quickly try it out we have pre-built yocto stacks for the Boundary Devices Sabre-Lite i.MX6 board and for customers of the NVIDIA DriveCX. For QNX, the tooling works with both QNX 6.6 and QNX Car 2 in combination with the native Application Manager and Compositor.


The goal of the Qt Automotive Suite is to make building of IVIs faster with a combination of software components, automotive APIs and tooling. It will be available under both commercial and Open Source licenses. This is just the start and we will be adding functionality and improving the tooling with each release. If you want to talk to someone about this fabulous new toolkit, please fill in the form https://www.qt.io/contact-qtauto.


The post Announcing The Qt Automotive Suite appeared first on Qt Blog.