For a few months now, we have been working on a new project under the codename Boot to Qt, and today we launch it as a technology preview.

Boot to Qt is a commercial offering that provides a fully integrated solution for the creation of slick user interfaces on embedded devices. The offering includes:

• A light-weight UI stack for embedded linux, based on the Qt Framework - Boot to Qt is built on an Android kernel/baselayer and offers an elegant means of developing beautiful and performant embedded devices.
• Ready-made images – We have images for several different devices which include the Boot to Qt software stack, making it possible to get up and running with minimal effort from day one.
• Full Qt Creator Integration – One-click deploy and run on hardware and a fully featured development environment.
• Simulator – A VirtualBox based simulator which allows device development without hardware and opens up for simulating hardware input, such as GPS and  connectivity.

This technology preview focuses on the stack built on an Android baselayer. We also want to provide a similar software stack and the same convenience with ready-made images and IDE integration also for traditional embedded Linux, hopefully with a preview coming some time this summer.

We are expecting to have an official release towards the end of this year.

The following video shows Boot to Qt in action on our reference hardware:

And the following video show the Boot to Qt SDK works:

Scope of Boot to Qt

The software stack includes most of the Qt Framework:

• Qt Core, Qt Gui, Qt Network, Qt Widgets, Qt Xml
• Qt QML and Qt Quick
• Qt Quick Controls
• Qt Graphical Effects
• Boot to Qt specific additions, including virtual keyboard, brightness control and power off/reboot functionality

The hardware devices supported in the Technology Preview are:

• Google Nexus 7 - 1.2 GHz Quad-Core ARM Cortex A9, Tegra 3 GPU, 1GB RAM
• Beagle Board xM - 1GHz ARM Cortex A8, PowerVR SGX530 GPU, 512MB RAM
• Boundary Devices SabreLite (Freescale i.MX 6) – 1 GHz Quad-Core ARM Cortex A9, Vivante GC2000 GPU, 1GB RAM

This is not a fixed set, but a place for us to start. If you have suggestions for other devices, let us know. The stack can also run on x86 hardware.

Performance

Qt 5 introduced a new OpenGL ES 2.0 based scene graph to power Qt Quick 2. This makes Qt Quick very suitable for running on embedded hardware, even those with moderate specs. The demo launcher we ship with the images for instance, runs velvet at 60 FPS on all our hardware devices.

We were looking at CPU usage while playing around in the application launcher on the Nexus 7. When idle, it uses a shader to add a glow on the currently selected item and has a small particle system on the Qt logo in the corner. We found that when the launcher was just animating the glow on the active item and running the small particle system on the Qt logo, the CPU load was running at about 50%. When we flicked it, it dropped to 30% and when the finger was down and we were moving the list via touch, it dropped to below 20%. So it seemed that the more we did, the less the CPU load became. What we were observing was CPU frequency scaling. The CPU is a Quad-core clocked at 1.2GHz (with a special 1.3Ghz single-core operating mode), but when idle, it had disabled 3 cores and had scaled the one remaining core to 102Mhz. So we were able to animate a large part of a 1280×800 screen at 60FPS on a CPU clocked at 102Mhz, and were still only using half of that. 

For reference, the same animation runs at 2% CPU on the i.MX6 and 15% on the Beagle, none of which does do frequency scaling.

We also have pretty decent startup times. Below is a diagram comparing Boot to Qt to native Android. Now of course, full Android brings in a lot of additional stuff, but that is also the point. Most embedded devices do not need that.

Startup times, in seconds, from power-on until device reaches the B2Qt launcher or the Android Homescreen.
Lower is better

This is not too shabby, but we believe we can cut this down a bit more, at least when we start exploring various embedded Linux configurations. As an example,  Qt 5 on Raspberry Pi can start rendering after as little as 3 seconds.

Getting Access

For more information, see the product page.

Boot to Qt is available for evaluation upon request. If you want to try it out or if you are just interested in the software, please use the contact form on the product page and we will be happy to get you started. Of course, feel free to leave comments and questions on this blog too.

Enjoy!

Digia has supported Metropolia University of Applied Sciences in their electric car project called Electric Raceabout (E-RA). This cool research project has produced a street legal electric sports car, which not only has the World record on ice, but also runs Qt.

Metropolia University, located in Helsinki, Finland, does extensive research on electric vehicles, one example being E-RA – an electric sports car built primarily by automotive engineering students.

With 4-wheel drive and well designed handling E-RA is a really capable sports car with impressive specs:

• Top speed of over 260 km/h
• Motor power of 282 kW
• Peak torque of 800 Nm – in each wheel

And all this provided by an electric vehicle that is fully street legal (and rest assured, the Finnish road inspection is surely one of the toughest in the world to pass).

E-RA has achieved lap time of 8 minutes 42,72 seconds at Nürburgring Nordschleife, which was electric vehicle track record for quite a while, as well as World record as the fastest electric vehicle on ice with average speed of 252,09 km/h. Nicely driven E-RA has operating range of over 200 kilometers.

The students have built both the IVI system and the instrument cluster with Qt 4.8 running on top of Linux. I think the whole E-RA project is a really great proof of the skills the soon-to-graduate engineers have, and certainly the Qt parts are no less impressive.

Have a look on the enclosed video produced by the students at Metropolia University to hear the full story:

If you want to create a QML application where the UI responds well to window resizing, the toolbox that Qt Quick offers has been somewhat limited. Qt 5.1 will offer the new Qt Quick types RowLayout, ColumnLayout and GridLayout for this purpose.

Background

Up until Qt 5.1, positioners and anchors have been the only Qt Quick tools available for arranging items in the UI.

Positioners are convenient for adding many items, but not always helpful for creating a resizable UI since they (as the name implies – surprise, surprise) only positions the items – the widths and heights are kept the same.

Anchors allows a bit more flexibility, at the price of verbosity. With anchors you can make an item stretch by binding one edge to the corresponding edge of the parent, and you set up a similar binding on the items’ opposite edge. However, you cannot make several items distribute themselves evenly if the window is resized.

The last option is to do the manual layouting yourself. This offers great flexibility, but it can be verbose, cumbersome and error-prone. During the development of Qt Quick Controls, we wanted to improve this and decided to provide a better and more convenient layout system.

import QtQuick.Layouts 1.0

By including the above import you will have RowLayout, ColumnLayout and GridLayout available in your toolbox. These layouts behave very much like their sisters found in the QtWidgets module: QHBoxLayout, QVBoxLayout and QGridLayout. It also tries to match the API of the Row, Grid and Column QML elements where it makes sense. So, if you are familiar with any of these APIs, you will find Qt Quick Layouts easy to grasp.

Alignment of items inside a cell can be specified with the Layout.alignment property.

Spans across rows or columns can be specified with the Layout.rowSpan and Layout.columnSpan properties.

Grid coordinates can be specified with the Layout.row and Layout.column properties.

Resizable items can be specified with the Layout.fillWidth and Layout.fillHeight properties. This was the main goal of the Qt Quick Layouts.

Minimum, Preferred and Maximum sizes can be specified with Layout.minimumWidth, Layout.preferredWidth and Layout.maximumWidth  properties (“Width” can be replaced with “Height” for specifying similar constraints to the height).

Example

ToolBar {
    Row {
        id: row
        spacing: 2
        anchors.verticalCenter: parent.verticalCenter
        ToolButton { iconSource: "images/go-previous.png" }
        ToolButton { iconSource: "images/go-next.png" }
    }
    Slider {
        anchors.left: row.right
        anchors.leftMargin: 2
        anchors.verticalCenter: parent.verticalCenter
        anchors.right: parent.right
    }
}

ToolBar {
    RowLayout {
        anchors.fill: parent
        spacing: 2
        ToolButton { iconSource: "images/go-previous.png" }
        ToolButton { iconSource: "images/go-next.png" }
        Slider { Layout.fillWidth: true }
    }
}

When writing JavaScript code, it doesn’t take long until I’m missing some function which is available in Qt’s C++ API. One very simple example is QList::contains. Checking whether an array contains a certain element works like this in JavaScript:

var names = ["Egon", "Peter", "Raymond", "Waldo"];
if (names.indexOf("Waldo") !== -1)
    print("We've found him!");

It would be nice if we could express the condition using a contains method but Array doesn’t provide one.
Luckily, JavaScript enables us to add methods to inbuilt types by modifiying the corresponding prototype object.

Array.prototype.contains = function(e) {
    return this.indexOf(e) !== -1;
}
if (names.contains("Waldo"))
    print("We've found him!");

Yay! Now we can use the contains method for all arrays!
But wait – there’s a surprise lurking right around the corner once you’re trying to iterate over the keys of the array.

for (var i in names)
    print(i);

This will print:

0
1
2
3
contains

I know, iterating over arrays should be done with an index variable…but still…this additional key is unexpected and asking for trouble.

The solution for this problem is to mark the property contains as non-enumerable. We can use the Object.defineProperty function for that which is available since JavaScript 1.8.5.

Object.defineProperty(Array.prototype, "contains", {
    value: function(e) { return this.indexOf(e) !== -1; },
    enumerable: false    // This is the default and can be omitted.
})

We’re passing to Object.defineProperty the object we want to enhance, the name of the property we want to add and a descriptor object that contains the attributes of our new property.
The value of  contains will be the function that we formerly passed directly to the prototype. Setting the enumerable property to false in the descriptor object will hide contains when using a for (... in ...) loop.

This way we can create a nice Qtish API for the inbuilt JavaScript types Array and String. This can be put into a .js file and used it in QML/JS or in qbs project files.

What do you think? Would such an API be helpful for your QML code? Which QList or QString method are you missing most?

I am happy to announce that we have today released Qt 5.1 Beta. We are now a major step closer to release Qt 5.1.0, which is expected before the summer. With the Beta release, binary installers for Qt 5.1 are available making it easier for you to get started with Qt. Let’s take a quick look at what is in the package.

Key functionality

The main driver for Qt 5.1 has been to increase the maturity of the new features introduced with Qt 5.0. We have improved the functionality and performance based on the feedback received from real-world use cases of Qt 5.0 and porting applications from Qt 4.x. We are able to meet your needs with Qt 5 because of the feedback and contributions from our growing ecosystem of about 500,000 developers in over 70 industries using Qt on numerous platforms and configurations.

The key new features of Qt 5.1 Beta include:

• Qt Quick Controls module providing a set of reusable UI components especially for desktop applications created with Qt Quick
• Qt Quick Layouts module bringing an easier, more intuitive, way to manage scalable UIs by ensuring that items are consistently arranged, and that the UI as a whole remains usable across different screen sizes.
• Qt Serial Port module providing a cross-platform interface for using hardware and virtual serial ports in Qt applications
• Possibility to use Qt Quick and Widgets together in the same application window
• Qt Creator 2.7.1 bundled into the package, providing, for example, Qt Quick Designer for rapid prototyping, as well as improved C++11 code editing
• Support for static Qt builds making it possible to address those use cases that cannot use dynamic linking
• Introducing Qt Sensors as an officially supported module

For a more detailed look, please take a look to the Wiki article listing the new features of Qt 5.1 Beta, refer to the Qt 5.1 Documentation Snapshot as well as the Known Issues page in the wiki.

Binary installers

For most users the big thing with Qt 5.1 Beta compared to Qt 5.1 Alpha is binary installers that provide a convenient way of installing all you need to start developing with Qt without needing to build Qt yourself. With Qt 5.1 we are introducing some new configurations such as 64bit VS2012 with OpenGL, which is already available with the Beta. Soon after the Beta we are upgrading MinGW to version 4.8 and aim to bring also 32bit VS2012 with ANGLE configuration by the time we are releasing Qt 5.1.0.

Qt 5.1 Beta comes as an offline installer, but we will also be providing online installers before the release of Qt 5.1.0 final. The offline installer contains all you need to get started with Qt – tools, documentation, examples and pre-built Qt libraries. Source packages are available for those who wish to build Qt (or need to use a configuration that is not available as a pre-built binary). In addition to the desktop binaries, Qt 5.1 Beta comes with pre-built binaries for Android that can be bundled in with your application.

New platforms

Qt 5.1 Beta provides technology-preview level implementation of the new Android and iOS ports. In addition, Qt 5.1.0 final is planned to re-introduce Windows Embedded Compact 7 support that has earlier been available with Qt 4.8. We have added all these new platforms into the CI system so that each change that goes into Qt is verified to work on these as well as the other platforms and configurations already in the CI. At the moment, the CI for Android and iOS only tests for building, but we are gradually also adding the automated tests to be run on these new platforms, to decrease the possibility of regressions.

There is quite a lot of buzz around the new mobile ports and many are interested in knowing what is possible already with the Qt 5.1 Beta. In general, it can be stated that you can create stunning applications that run smoothly on both of the new platforms, but with limitations in supported functionality and the developer experience of getting your masterpiece into these devices.

With Android the following functionality works quite well in the Qt 5.1 Beta:

• Widgets, Graphics View, Qt Quick 1 and Qt Quick 2 applications
• OpenGL, networking and other core functionalities of Qt
• Some parts of Qt Multimedia, for example QML media player
• A set of commonly used sensors with Qt Sensors
• Deploying your application to a device from Qt Creator
• Debugging your application from Qt Creator
• Qt 5.1 Beta comes with pre-built binaries for Android that can be bundled in with your application

With iOS the main issue is Qt Quick 2 not being available, as it needs a new QML engine, but the following functionality works quite well in the Qt 5.1 Beta:

• Widgets, Graphics View and Qt Quick 1 applications
• OpenGL, networking and other core functionalities of Qt
• A set of commonly used sensors with Qt Sensors
• Deploying your application to a device from Xcode / iTunes

Next steps

With the release of Qt 5.1 Beta we are one step closer to the Qt 5.1.0 final release, which we aim to have out before summer. Based on the feedback we receive from the Beta, there will be a Release Candidate created in a few weeks time, or alternatively a second Beta.

Please test out Qt 5.1 Beta and send us feedback:

• File a bug report to bugreports.qt-project.org in case you find a new bug
• Send e-mail to Qt Project mailing lists or contact us via IRC
• If you have a commercial license, please contact Digia Qt Support via the Customer Portal

Qt 5.1 Beta release can be downloaded from the Digia Qt Customer Portal or from download.qt-project.org for open-source users.

Guggenheim mirror balls

Registration for the Qt Contributors Summit 2013 is now open.

Before going into details, I’ve added a photo of the The Guggenheim mirror balls right outside the famous Guggenheim Museum in Bilbao. It can symbolise how every Qt contributor is linked together, working on the same project, using the summit to reflect on how Qt can be developed even better. Ok, Knut, snap out of it. Over to the practicalities.

Qt Contributors Summit 2013 registration is easy. Just use the Qt CS registration form.

Since the Qt Contributors Summit is an invitation-only event, please make sure you fit into one or more of the following before registering:

• You are a Qt Project maintainer
• You are a Qt Project approver
• You took part in the previous Summit (Attendees at Qt CS 2012)
• You took a sponsorship package including event invitations (coming soon)
• You are in the organization team.
• You are invited by a maintainer or the organization team and we still have seats left.
• KDE Akademy contributor

Please add sessions unconference style

Since the main idea for the Qt CS is to let developers meet and make solutions, now is the time to pre-schedule sessions on the Qt CS program wiki. Please press “Join group” at the top of the wiki-page. We will  give you wiki-access as soon as possible and add you to the group.

We take today’s Qt 5.1 beta release as an opportunity to push out some fixes to Qt Creator 2.7.

Around 40 bugs reported on our bugtracker have been fixed, so if you wonder if your favorite issue is one of them you might want to check out the list of “Qt Creator bugs that have been closed as ‘done’ for 2.7.1″ on our bug tracker. And of course there were other bugs fixed that do not appear on that list, so you should definitely check Qt Creator 2.7.1 out.

Download Qt Creator 2.7.1

In Qt you can create multiple document interface (MDI) applications using a QMdiArea as the central widget. The QMdiArea widget serves as a window manager for the MDI windows. There are already functions available for tiling all the child windows into a tile pattern and for cascading them into a cascade pattern.

With MDI application it would sometimes be useful to tile the child windows also horizontally and vertically. The QMdiArea does not currently have an API to achieve this functionality but it’s quite simple to arrange the child windows in your application. We will next cover the steps needed to tile the child windows horizontally and vertically. The approach presented here is implemented on top of the MDI Example (http://qt-project.org/doc/qt-5.0/qtwidgets/mainwindows-mdi.html).

Let’s start by adding the actions in place so that the functionality can be triggered. To the MainWindow we will add one action for each function as private member variable:

QAction *tileVerticalAct;
QAction *tileHorizontalAct;

We will also add a private slot for each function:

void tileSubWindowsVertically();
void tileSubWindowsHorizontally();

Then we will initialize the actions and connect them to the right slots. We are going to add the following code to the createActions() method that already initializes actions for the application:

tileVerticalAct = new QAction(tr("Tile Vertically"), this);
tileVerticalAct->setStatusTip(tr("Tile the windows vertically"));
connect(tileVerticalAct, SIGNAL(triggered()), this, SLOT(tileSubWindowsVertically()));

tileHorizontalAct = new QAction(tr("Tile Horizontally"), this);
tileHorizontalAct->setStatusTip(tr("Tile the windows horizontally"));
connect(tileHorizontalAct, SIGNAL(triggered()), this, SLOT(tileSubWindowsHorizontally()));

And naturally we need to add the actions to the menu in order to launch the tiling. We can do this in the updateWindowMenu() where other actions are added to the menu too:

windowMenu->addAction(tileVerticalAct);
windowMenu->addAction(tileHorizontalAct);

Now we are ready to start tiling the child windows. We are going to take a closer look at the tileSubWindowsVertically() slot here. To begin with, we will start by checking that there are child windows in the MDI area to prevent us from trying to do modifications to non-existing windows.

if (mdiArea->subWindowList().isEmpty())
    return;

We are going to initialize a rectangle that defines the size of one child window. The width for a child window will naturally be the width of the MDI area. The height of a child window will be based on the height of the MDI area and the amount of child windows. Basically, we will just divide the MDI area height with the amount of child windows. The rectangle can then be used to set the geometry for each child widget in the MDI area.

QPoint position(0, 0);

foreach (QMdiSubWindow *window, mdiArea->subWindowList()) {
    QRect rect(0, 0, mdiArea->width(), 
               mdiArea->height() / mdiArea->subWindowList().count());
    window->setGeometry(rect);
    window->move(position);
    position.setY(position.y() + window->height());
}

While we are setting the geometry for the child widgets we also define the new position for them to have the windows tiled vertically. The child windows are ordered here based on the order of the child windows in the MDI area. By default, this order is the order in which the windows were inserted into the workspace. We will move the first window in the MDI area to the top left corner. While processing the child windows we will adjust the position so that each child window is position below the previously processed one. This is all we need to tile the child windows vertically.

Tiling the child windows horizontally will be almost the same; you only need to adjust the width and x-position of the window. The height of a child window will be the same as the height of the MDI area. The position of a child window will be on the right of the previous child.

void MainWindow::tileSubWindowsHorizontally()
{

    if (mdiArea->subWindowList().isEmpty())
        return;

    QPoint position(0, 0);

    foreach (QMdiSubWindow *window, mdiArea->subWindowList()) {
        QRect rect(0, 0, mdiArea->width() / mdiArea->subWindowList().count(), 
                   mdiArea->height());
        window->setGeometry(rect);
        window->move(position);
        position.setX(position.x() + window->width());
    }
}

Not that hard or what do you think? If you want to give it a try you can get the source code for the example here: Source code for example application . Shall you have any questions related to this you can always contact us in the Qt Support team via the Customer Portal.

You may have already heard of Enginio at Qt Developer Days 2012  or you may have stumbled across our site, http://engin.io. We are now ready to officially open up the doors to our Enginio Tech Preview and welcome you to test it out. We have already had some early adopters who have given us valuable feedback which we have used to develop the product.

Why Enginio?

When we had a look at the existing cloud solutions, we saw that there was room for improvement. They were sometimes difficult to get started using and required specific knowledge of certain infrastructures or platforms and in most cases did not have Qt/C++ APIs. Using the experience we have from building backend solutions for various kinds of applications, we decided to create a solution that linked applications with a backend cloud storage based on Qt’s intuitive APIs. With Enginio developers can concentrate on creating their application making it visually pleasing and performing and let Enginio manage the backend functionality, scalability, security and performance.

Our goal was to build upon Qt’s motto of making “developer’s lives easier” and so what we wanted to do was provide developers with an uncomplicated and stress-free development experience in the backend. So, we started to create a solution that was easy to use and value-adding for Qt application development and at the same time transmit that Qt effortless development trait to other platforms. We want to make sure that the value-adding benefits of having a Qt backends are available to all. Enginio will be commercially available for both open-source and enterprise Qt users. For enterprise Qt users developing with a commercial license, a few additional value-adding features and functions will be made available to them later on.

The Enginio Technology Previews supports:

• Web dashboard (UI for configuring & managing your backend)
• Schema-less data storage (Place to store your application data)
• Security model (Mechanism to control which end-users can access what data)
• File support (Save small or large files in the cloud)
• Full text search (Search stored data by its content)
• Qt/QML client library (Convenient way to create applications)

How to get started?

1. Sign up for an Enginio account

2. Setup your new backend

3. Develop your App

The latest release version of the Qt library is available from the Enginio dashboard.

Shared library and QML extension plugin are built and installed as usual with `qmake && make && make install`

Qt example:

I. In Qt Creator choose File > New File or Project… and create new “Qt Gui Application”.
II. In the new project’s pro file add:

QT += network
win32:CONFIG(debug, debug|release): LIBS += -lenginioclientd
else: LIBS += -lenginioclient

III. In MainWindow.cpp:

// Include Enginio headers
#include <Enginio/Enginio>

// Instantiate Enginio Client
// Copy your backend ID and secret from Enginio dashboard
const QString backendId("YOUR_OWN_BACKEND_ID");
const QString backendSecret("YOUR_OWN_BACKEND_SECRET");
EnginioClient *client = new EnginioClient(backendId, backendSecret);

// Create new object to backend
EnginioJsonObject banana("objects.fruits");
banana.insert("name", QStringLiteral("Banana"));
banana.insert("price", 1.59);
EnginioObjectOperation *createOp = new EnginioObjectOperation(client);
createOp->create(banana);
createOp->execute(); // Initiates asynchronous operation

// Fetch objects from backend to list model
EnginioObjectModel *objectModel = new EnginioObjectModel();
EnginioQueryOperation *queryOp = new EnginioQueryOperation(client);
queryOp->setObjectType("objects.fruits");
queryOp->setModel(objectModel);
queryOp->execute();

QML example:

I. In Qt Creator choose File > New File or Project… and create new “Qt Quick 2 Application (Built-in Elements)”
II. In main.qml:

import io.engin 1.0 as Enginio

// Instantiate Enginio Client
// Copy your backend ID and secret from Enginio dashboard
Enginio.Client {
	id: client
	backendId: "YOUR_OWN_BACKEND_ID"
	backendSecret: "YOUR_OWN_BACKEND_SECRET"
}

Enginio.ObjectModel {
	id: objectModel
}

Enginio.QueryOperation {
	id: queryOp
	client: client
	model: objectModel // Query results are added to model
	objectTypes: ["objects.fruits"] // Get all fruit objects
}

Component.onCompleted: {
	// Create new object to backend
	var banana = {
		objectType: "objects.fruits",
		name: "Banana",
		price: 1.59
	};
	var createOp = client.createObjectOperation();
	createOp.create(banana);
	createOp.execute();
	createOp.finished.connect(function() {
		// Fetch objects from backend to list model
		queryOp.execute();
	});
}

Build and your connected application is ready.

We would like to invite more people to test and provide feedback. However, please bear in mind that the service is still under development and you may experience some bugs, changes and breaks. Go and check it out at http://engin.io. Let us know what you think!

You can reach the Enginio development team at mailus@engin.io.

Qt 5.0 added basic support for retina reasonable resolution displays. The upcoming Qt 5.1 will improve the support with new API and bug fixes. Qt 4.8 has good support, and backports of some of the Qt 5 patches are available.

While this implementation effort is mostly relevant to Mac and iOS developers, it is interesting to look at how other platforms handle high-dpi displays. There are two main approaches:

• DPI-based scaling – Win32 GDI and KDE. In approach the application works in the full physical device resolution and is provided with a DPI setting or scaling factor, which should be used to scale layouts. Fonts are automatically scaled by the OS (as long as you specify the font sizes in points and not pixels)
• Pixels By Other Names. In this approach the physical resolution is (to various degrees) hidden to the application. Physical pixels are replaced with logical pixels:
  

  Platform/API	Logical	Physical
  HTML	CSS pixel	Device pixel
  Apple	Point	Pixel
  Android	Density-independent pixel (dp)	(Screen) Pixel
  Direct2D	Device Independent Pixel (DIP)	Physical Pixel
  Qt (past)	Pixel	Pixel
  Qt (now)	Device-Independent Pixel	Device Pixel

Qt has historically worked in device pixels with DPI scaling. Back in 2009 support for high DPI values on Windows was improved. The Qt layouts do however not account for increased DPI. Qt 5 now adds support of the “new pixels” type of scaling.

(Are there other high-dpi implementations out there? Use the comments section for corrections etc.)

Mac OS X High-dpi Support

The key to the OS X high-dpi mode is that most geometry that was previously specified in device pixels are now in device-independent points. This includes desktop geometry (which on the 15 inch retina MacBook Pro is 1440×900 and not the full 2880×1800), window geometry and event coordinates. The CoreGraphics paint engine is aware of the full resolution and will produce output at that resolution. For example, a 100×100 window occupies the same area on screen on a normal and high-dpi screen (everything else being equal). On the high-dpi screen the window’s backing store contains 200×200 pixels.

The main benefits of this mode is backwards compatibility and free high-dpi vector graphics. Unaware applications simply continue to work with the same geometry as before and can keep hardcoded pixel values. At the same time they get crisp vector graphics such as text for free. Raster graphics does not get an automatic improvement but is manageable. The downside is the inevitable coordinate system confusion when working with code that mixes points and pixels.

The scale factor between points and pixels is always 2x. This is also true when changing the screen resolution – points and pixels are scaled by the same amount. When scaling for “More Space” applications will render to a large backing store which is then scaled down to the physical screen resolution.

Scaling the user interface resolution on Mac OS

If you don’t have access to retina hardware there is also an emulation mode which can be useful when used on an extra monitor. Open Display Properties and select one of the HiDPI modes. (See this question on stack overflow if there are none.)

Enabling high-dpi for OS X Applications

High DPI mode is controlled by the following keys in the Info.Plist file:

<key>NSPrincipalClass</key>
<string>NSApplication</string>
<key>NSHighResolutionCapable</key>
<string>True</string>

Qmake will add these for you. (Strictly speaking it will only add NSPrincipalClass, NSHighResolutionCapable is optional and true by default).

If NSHighResolutionCapable is set to false, or the keys are missing, then the application will be rendered at the “normal” resolution and scaled up. This looks horrible and should be avoided, especially since the high-dpi mode is very backwards compatible and the application gets a lot of high-dpi support for free.

Scaled Qt Creator

High DPI Qt Creator

 
(Appart from a patch to update the “mode” icons, this an unmodified version of Qt Creator.)

Qt implementation details

Mac OS 10.8 (unofficially 10.7?) added support for high-dpi retina displays. Qt 4 gets this support for free, since it uses the CoreGraphics paint engine.

Qt 5 uses the raster paint engine and Qt implements high-dpi vector graphics by scaling the painter transform. HITheme provides high-dpi Mac style for both Qt 4 and 5. In Qt 5 the fusion style has been tweaked to run well in high-dpi mode.

OpenGL is a device pixel based API and remains so in high-dpi mode. There is a flag on NSView to enable/disable the 2x scaling – Qt sets it in all cases. Shaders run in device pixels.

Qt Quick 1 is built on QGraphicsView which is a QWidget and gets high-dpi support through QPainter.

Qt Quick 2 is built on Scene Graph (and OpenGL) which has been updated with high-dpi support. The Qt Quick Controls (née Desktop Components) has also been updated to render in high-dpi mode, including using distance field text rendering.

The take-away point here is that for app developers this doesn’t matter, you can do most of your work in the comfort of the device-independent pixel space while Qt and/or the OS does the heavy lifting. There is one exception which is raster content – high-dpi raster content needs to be provided and correctly handled by application code.

Widgets and QPainter

QPainter code can mostly be kept as is. As an example lets look at drawing a gradient:

QRect destinationRect = ...
QGradient gradient = ...
painter.fillRect(rect, QBrush(gradient));

On high-dpi displays the gradient will have the same size on screen but will be filled with more (device) pixels.

Drawing a pixmap is similar:

QRect destinationRect = ...
QPixmap pixmap = ...
painter.drawPixmap(destinationRect, pixmap);


To avoid scaling artifacts on high-dpi displays the pixmap must contain enough pixels: 2x the width and height of destinationRect. The application can either provide one directly or use QIcon to manage the different resolutions:

QRect destinationRect = ...
QIcon icon = ...
painter.drawPixmap(destinationRect, icon.pixmap(destinationRect.size()));


QIcon::pixmap() has been modified to return a larger pixmap on high-dpi systems. This is a behavior change and can break existing code, so it’s controlled by the AA_UseHighDpiPixmaps application attribute:

qApp->setAttribute(Qt::AA_UseHighDpiPixmaps);


The attribute is off by default in Qt 5.1 but will most likely be on by default in a future release of Qt.

Edge cases and devicePixelRatio

Qt Widgets has some edge cases. Ideally it would pass QIcons around and the correct pixmap would be select at draw time, but in reality Qt API often produces and consumes pixmaps instead. This can cause errors when the pixmap size is used for calculating layout geometry – the pixmap should not use more space on screen if it’s high-resolution.

To indicate that a 200×200 pixmap should occupy 100×100 device-independent pixels use QPixmap::devicePixelRatio(). Pixmaps returned from QIcon::pixmap() will have a suitable devicePixelRatio set.

QLabel is one “pixmap consumer” example:

QPixmap pixmap2x = ...
pixmap2x.setDevicePixelRatio(2.0);
QLabel *label = ...
label->setPixmap(pixmap2x);


QLabel then divides by devicePixelRatio to get the layout size:

QSize layoutSize = pixmap.size() / pixmap.devicePixelRatio();


Several issues like this has been fixed in Qt, and application code can have similar code that needs to be corrected before enabling AA_UseHighDpixmaps.

The devicePixelRatio() accessor is available on several Qt classes:

Text

Font sizes can be kept as-is, and produce similarly-sized (but crisp) text on high-dpi displays. Font pixel sizes are device-independent pixel sizes. You never get tiny text on high-dpi displays.

QGlWidget

OpenGL operates in device pixel space. For example, the width and height passed to glViewport should be in device pixels. QGLWidget::resizeGL() gives the width and height in device pixels.

However, QGLWidget::width() is really QWidget::width() which returns a value in device-independent pixels. Resolve it by multiplying with widget->windowHandle()->devicePixelRatio() if needed.

Qt Quick 2 and controls

Qt Quick 2 and the Qt Quick Controls work well out-of-the box. As with widgets coordinates are in device-independent pixels. Qt Quick has fewer raster-related edge cases, since the QML Image element specifies the image source as a url which avoids passing around pixmaps.

Qt Quick Controls

One exception is OpenGL shaders that run in device pixel space and see the full resolution. This is usually not a problem, the main thing to be aware of is that mouse coordinates are in device-independent pixels and may need to be converted to device pixels.

shadereffects example in action

Managing high-resolution raster content

As we have seen, raster content won’t look nice when scaled and high-resolution content should be provided. As an app developer you have two options: (ignoring the “do-nothing” option)

• Replace existing raster content with a high-resolution version
• Provide separate high-resolution content

The first option is convenient since there is only one version of each resource. However, you may find (or your designer will tell you) that resources like icons look best when created for a specific resolution. To facilitate this, Qt as adopted the “@2x” convention for image filenames:

foo.png
foo@2x.png


High-resolution content can be provided side-by-side with the originals. The “@2x” version will be loaded automatically when needed by the QML Image element and QIcon:

Image { source = “foo.png” }
QIcon icon(“foo.png”)

(remember to set AA_UseHighDpiPixmaps for QIcon)

Experimental cross-platform high-dpi support:

QPA allows us to relatively easily make a cross-platform implementation. The Qt stack can be divided into three layers:

1. The Application layer (App code and Qt code that uses the QPA classes)
2. The QPA layer (QWindow, QScreen, QBackingStore)
3. The platform plugin layer (QPlatform* subclasses)

Simplified, the application layer operates in the device-independent pixel space and does not know about device pixels. The platform plugins operates in device pixel space and does not know about device-independent pixels. The QPA layer sits in between and translates, based on a scale factor set by the QT_HIGHDPI_SCALE_FACTOR environment variable.

In reality the picture is a little bit more complicated, with some leakage between the layers and the special Mac and iOS exception that there is additional scaling on the platform.

Code is on github. Finally, screenshots of Qt Creator on XCB:

DPI scaled Qt Creator

QT_HIGDPI_SCALE_FACTOR=2 Scaled Qt Creator

Six months ago we laid out Digia’s Qt strategy at Qt Developer Days 2012 and since then we have been working together with the community to achieve our goals of increasing the use of Qt and expanding business opportunities for all members of the Qt ecosystem and Digia.

I wanted to explain a bit more in detail via this blog post how Digia plans to keep Qt in the lead position, thriving and continuously evolving as well as give a state of the union as we mark our 6-month milestone.

2017 Goals

First, let’s quickly re-cap what we have set as our goals for the next few years.

• #1 in multi-platform support
• #1 in developer experience
• #1 in creating great user experiences
• Strong value-generating ecosystem
• Dual licensing model
• Open business architecture

We have made great progress in many of these already in the past few months, so I think we are definitely in the right track to reach these together.

#1 in Multi-Platform Support

Qt is by nature a cross-platform development framework, which has supported a large number of desktop, embedded and mobile platforms. In the past few months, we have been actively working on introducing support for Android and iOS as well as improving the experience on the desktop and embedded platforms. With the soon–to-be released Qt 5.1 we will already be able to provide solid technology previews for both Android and iOS, which we expect to be complete for Qt 5.2 coming out before the end of this year. We are also working with the WinRT port of Qt to be available soon after Android and iOS. With the introduction of support in Qt 5.1 for the leading mobile platforms, Qt jumps to the next phase of being a platform agnostic world-class and all-around cross-platform software development framework.

#1 in Developer Experience

We have started a few projects to make developers’ encounters with Qt easy and effortless. In Qt 5.0 we tightly coupled Qt Creator and other tools into the same Qt package together with the libraries making it possible to get everything they need to start developing with Qt all in one place. It is still possible to develop for Qt with other IDEs than Qt Creator – for example with Visual Studio or XCode. We have also been working with the online installers for Qt 5, which will be available soon and further improve the experience of developing with Qt. We are also investing heavily into tooling. Focusing on, for example, the new Qt Quick Designer, which was first released with Qt Creator 2.7, and the new Qt Quick Controls of which the first set will come in Qt 5.1.

#1 in Creating a Great User Experience

Qt is known for its ability to create amazing user experiences.  We are working hard to continue Qt’s position as the leading software development framework that enables the creation of stunning UIs with an unbeatable graphics performance. The new graphics pipeline of Qt 5 is one of the cornerstones to reach this goal.  Qt Quick 2 offers a GL-based scene graph, a particle system and a collection of shader effects for fun and cool animations, amongst other things, as well as Qt Multimedia and Qt Graphical Effects that lets the developer bring motion and sound to life within their application.  We will continue to improve these capabilities and make it even easier to build stunning applications with Qt.

Strong Value Generating Ecosystem

In addition to actively working with the developer community through the Qt Project, we are making good progress with our Digia Qt Partner Program with the first partners already signed on and many more to be enrolled soon. We are actively working with members of the Qt community to make sure that valuable Qt events and activities are possible.

This year, the Qt Contributors Summit and KDE Akademy will be held jointly where two strong communities can leverage from each other’s expertise. Digia is a platinum sponsor at this year’s combined Qt Contributor Summit and KDE Akademy. Following last year’s successful Qt Developer Days in Berlin and California, Digia will again join forces with KDAB and ICS to put Qt Developer Days 2013. Lastly, this June, Digia together with top sponsors and active Qt community participants BlackBerry and Jolla, will host the Qt Developer Day China in Beijing (June 6) to cater to our growing Qt ecosystem in China.  We believe that by working together in the ecosystem we can jointly take Qt forward at an unbeatable speed and benefit from the growing user base of developers making Qt-based solutions in over 70 different industries including free software.

Dual Licensing Model

We believe that the dual licensing model is crucially important for the whole Qt ecosystem to thrive, and that it is the best way to further develop Qt. The full development of Qt and making it the leading cross-platform application development framework is at the cornerstone of Digia’s strategy. This means that we want all developers, organizations, companies around the world regardless of industry, business model, device types etc., to use Qt to further their own development goals and business strategies.

In order to keep Qt in the lead allowing innovation into our development, it is important that Qt is available for commercial users and the open source community and provide the functionality that meet the varying needs of both. We believe in the power of open-source development in fostering innovation and value very much all the things we do together with the Qt community via the Qt Project. The dual licensing model serves two purposes in driving Qt forward:

• Commercial licensing secures future investments into Qt R&D with the financial stability needed to keep the Digia Qt engineering teams producing invaluable code development and contributions. Revenue generated from the commercial license sales also enables the Qt Project to charge forward securing, for example, the infrastructure, repositories and qt-project.org servers and development to be a community arena for Qt development where all can participate and contribute.
• Qt open-source development provides an incomparable vehicle to make Qt available everywhere for everybody increasing the Qt user base and promoting adoption of the technology.

Both of the above models work hand-in-hand; without one our goals of bringing Qt to all and making it the world’s leading cross-platform development framework are not fully possible. Our new mobile ports of Qt for Android, and iOS as well as the upcoming WinRT port are fully developed in the open, a very strong proof point that we really do believe in dual licensing also in the future.

Open Business Architecture

Tightly related with the strong value generating ecosystem is open business architecture – a new element in the Qt ecosystem. We believe that enabling more business opportunities for everybody via Qt will be beneficial for the entire ecosystem.  Open business architecture is a principle that defines the rules for an equal playing ground where everybody is invited to participate. At this point, we see this as a principle, but later on we hopefully are able to develop the whole business architecture forward in such way – and enable more business for everybody.

With an open and thriving Qt ecosystem, we believe that Digia and other players in the community can provide value-adding products for functionality, tools and services. We believe that having such additional components available not only provides more business opportunities for all interested companies, but also makes Qt stronger. The more there are ready-made solutions available to meet the needs and challenges in various industries and use cases, the more value Qt offers our users.

Adding Value

Digia is seeking to create added value in mainly the following areas:

•    Value-adding functionality especially for enterprise users and in the embedded space
•    Improved tools providing a shortened time-to-market and cost savings for companies using Qt
•    Cloud-based services than can be used in conjunction with solutions built with Qt
•    Support and services for development with Qt

Some examples of these are already available; for example, the Charts library and the improved Visual Studio Add-In, as well as our support and services offering. We are working on a new cloud-based backend for Qt applications called Enginio, which was first presented at the Qt Developer Days last year. We are very close to launching the public technology preview, so stay tuned for it.

Especially for our enterprise and embedded customers, we have been working with additional tools that can be plugged into the Qt Creator IDE to make developing with Qt even more efficient, as well as to meet the growing demands of our customers and companies who have chosen Qt as their strategic development choice and who require a full commitment from Digia to succeed in their industry.   We believe that it is possible to provide these refinements of Qt for many different industries, and are aiming to develop Qt and our tooling offering further to allow also other members of the Qt community to offer these as part of the open business architecture.

All in all, I am very happy with the progress we have made towards the goals we set for Qt last year. I am extremely pleased that we have been able to work towards these with so many great partners, customers and community members that form the Qt ecosystem. I believe that by continuing this together we will be able to take Qt forth at record pace and truly make it the number #1 choice for cross-platform application and UI development.

We would love to hear from you, so please drop us a note in the comments below. Happy Qt development!

Background

After Friedemann has given an initial introduction about Qt’s Windows Runtime port, I would like to give some further insight about technical aspects and our ways of working on the port.

When reading about Windows Runtime development (Windows 8 store applications and Windows runtime components) in connection with C++ you will find C++/CX again and again. Windows C++/CX are C++ language extensions which were developed by Microsoft to make software development for Windows Runtime easier by bringing it “as close as possible to modern C++” (Visual C++ Language Reference (C++/CX)). In some cases, these extensions look similar to C++/CLI constructs, but they might have other meanings or slightly different grammar.

The first thing that catches someone’s eye when one has a look at C++/CX documentation or an example/application are lines like
Foo ^foo = ref new Foo();
The ^ is basically a pointer, but gives the additional information that it is used on a ref-counted COM object so that memory management happens “automagically”. The “ref new” keyword means that the user wants to create a new “Ref class” (see Ref classes and structs in Type System (C++/CX)), which means that it is copied by reference and memory management happens by reference count.  So there isn’t much magic involved in that line; it only tells the compiler that the object’s memory can be managed by reference count and the user does not have to delete it himself.

Basically C++/CX is just what its name tells us it is – extensions to the C++ language. Everything ends up as native unmanaged code quite similar to the way Qt works. Some people might argue whether it is necessary to reinvent the wheel for the n-th time where a lot of the “problems” are actually solved in C++11 (by the way, auto foo also works in the example above), but that is what was decided for Windows Runtime development.

Use of C++/CX inside Qt’s WinRT port

Microsoft has said on different occasions (among others during the Build conference 2012) that everything that can be done using C++/CX can also be done without the extensions, as everything ends up as native code in either case. So we had to decide whether we want to use the new fancy stuff or take the cumbersome road of manual memory management etc. Theoretically there is nothing that keeps us from using C++/CX in Qt’s WinRT port, but there are some reasons why we try to avoid them.

For one, these extensions might prevent developers who are willing to help with the Windows Runtime port from having a deeper look at the code. If you do not have any previous experience with this development environment, having new constructs and keywords (in addition to new code) might be enough for you to close the editor right away. While WinRT code which doesn’t use CX might not be especially beautiful, there are no non-default things which might obscure it even more.

Another issue is that Qt Creator’s code model cannot handle these extensions (yet). You don’t get any auto completion for ^-pointers, for example. This can of course be fixed in Qt Creator and time will tell whether it will be, but at the moment the port and basic Qt Creator integration (building, debugging & deployment) are our first priorities.
Due to these facts, we decided that we do not want to use the extensions. Though, if someone wants to help out with the port and is eager to use CX he/she might be able to persuade us to get the code in (after proper review of course ).

Problems and challenges of not using C++/CX

The main problem when it comes to development of Windows Runtime code without using C++/CX is the severe lack of documentation. While the MSDN documentation generally can be improved in certain areas, it almost completely lacks anything about this topic. But thanks to Andrew Knight, who gave me an initial overview how things are to be used and was always helpful whenever I had additional questions, I think I am getting the grip on things. In order to help others who want to join the efforts (and have all the things written down), I will cover some basic areas below.

Namespaces

The namespaces given in the documentation are always the same for the CX usage of the classes,  just with “ABI” added as the root namespace. So for StreamSocket, Windows::Networking::Sockets becomes ABI::Windows::Networking::Sockets. Additionally, you probably need Microsoft::WRL (and also Microsoft::WRL::Wrappers). WRL stands for “Windows Runtime C++ Template Library” and is used for direct COM access in Windows Runtime applications – but you will also need its functionality when omitting CX (for creating instances for example).

Creating instances

When not using CX, most of the classes cannot be accessed directly. Instead, there are interface classes which need to be used. These interfaces are marked by an ‘I’ in front of the class name so that StreamSocket becomes IStreamSocket. As these interfaces are abstract classes, they cannot be instantiated directly. First of all, you have to create a string which represents the class’s classId.
HStringReference classId(RuntimeClass_Windows_Networking_Sockets_StreamSockets);

These RuntimeClass_Windows… constructs are defined in the related header files and expand to strings like “Windows.Networking.Sockets.StreamSocket” for example. The way objects can be instantiated depends on whether the class is default constructable or not. If it is, ActivateInstance can be used to obtain an object of the type you are after.

IStreamSocket *streamSocket = 0;
if (FAILED(ActivateInstance(classId.Get(), &streamSocket)) {
// handle error
}


Unfortunately, the ActivateInstance convenience function fails for StreamSocket in that case as it expects a ComPtr as parameter. In order to avoid that failure one has to take the long way using RoActivateInstance

IInspectable *inspectable = 0;
if (FAILED(RoActivateInstance(classId.Get(), &inspectable)) {
// handle error
}
if (FAILED(inspectable->QueryInterface(IID_PPV_ARGS(&streamSocket)))) {
// handle error
}


If the class is not default constructable, it has to use a factory in order to create instances. These factories can be obtained by calling GetActivationFactory with the appropriate class Id. One example of a class like that would be HostName:

IHostNameFactory *hostnameFactory;
HStringReference classId(RuntimeClass_Windows_Networking_HostName);
if (FAILED(GetActivationFactory(classId.Get(), &hostnameFactory))) {
// handle error
}
IHostName *host;
HStringReference hostNameRef(L"http://qt-project.org");
hostnameFactory->CreateHostName(hostNameRef.Get(), &host);
hostnameFactory->Release();


People who are used to Windows development probably have already noticed that all this is COM based. That means that all this has been around for ages and is loved everywhere.

Calling static functions

For classes which have static functions there is an extra interface for these functions. These interfaces are marked by “Statics” at the end of the “basic” interface name and can also be obtained by using GetActivationFactory. One example would be IDatagramSocketStatics which contains GetEndpointPairsAsync for example.

IDatagramSocketStatics *datagramSocketStatics;
GetActivationFactory(HString::MakeReference(RuntimeClass_Windows_Networking_Sockets_DatagramSocket).Get(), &datagramSocketStatics);


IAsyncOperation<IVectorView *> *endpointpairoperation;
HSTRING service;
WindowsCreateString(L"0", 1, &service);
datagramSocketStatics->GetEndpointPairsAsync(host, service, &endpointpairoperation);
datagramSocketStatics->Release();
host->Release();


The endpointpairoperation defines the callback(s) for this asynchronous function, but that topic could be covered in another post. The interesting parts here are how the datagramSocketStatics pointer is filled by calling GetActivationFactory and the actual call to the static function by datagramSocketStatics->GetEndpointPairsAsync(...).

ComPtr

There is a way to use reference counted memory management even without using CX. It can be achieved by using the Microsoft-provided smart pointer ComPtr. So
IStreamSocket *streamSocket
would become
ComPtr<IStreamSocket> streamSocket.
When using these, we had some memory access errors we could not explain (but did not investigate much further). In addition to that, Qt Creator does not support code completion with “streamSocket->” but one would have to call “streamSocket.Get()->”. Thus we decided not to use ComPtr but keep using “normal” pointers. All you have to do is to remember to call “Release” as soon as you are done with the pointer.

All in all, we try to avoid these extensions even though it might not make the code beautiful. If you want to contribute though and feel at home using these, feel free to create a patch containing CX code. If you have any further questions or advice, feel free to add them in the comments or join us in #qt-winrt on freenode.

Right before Qt Developer Days in Berlin, November 2012, we began discussing with the qt-project.org moderators how to bring rest of the Qt Project into Open Governance. This includes the content management system, forums, wikis and so on – everything run as a real community-driven project, as the Qt development itself has been run since October 2011.

This figure shows the different roles in the Open Governance structure. A detailed explanation is found on the Web Open Governance page[1].

To make a proper plan, we’ve been running a series of structured IRC meetings, open for all, starting in December last year, continuing through February this year. As the meeting summaries show[2], we started the planning sessions with a discussion on the purpose of the Qt Project Web. Then we continued with discussion and investigation on how maintenance can be done, including co-development of the web content management system. Technical issues, such as improvement with single sign-on and improvements to the wiki-system were discussed. Privacy, internationalization and license issues have also been looked at.

Here are some key topics and actions crystallizing out of these meetings:

• Single sign-on and a wiki which handles merges (not losing work) Enabling system rights for developing, testing and rolling out new features, including maintenance has to be established.
• From a roles perspective: several new roles with extended rights are needed, especially giving more access to different admin rights as group management and access to specific web pages.
• From a process perspective: lazy approval, task prioritization and a conflict resolution board, if needed, in case of (hopefully very few) unresolved conflicts.
• Also the licensing issue was raised, making the Qt Project Web user agreement clearer, also including licensing to maintain privacy when doing system administration, testing, and development tasks on the site.

Next steps

We are now working on four parallel activities to make Open Governance happen.

• For CMS development, we are on our way to implement a three-stage infrastructure with a development server and a staging server before production. Today, this is a two-stage setup. We want three stages, which allows the OS to be more flexible in doing the development.
• We are working at implementing a new access-rights model to allow access to different parts of the CMS.
• We have identified the need for a “system admin” agreement which is needed before granting extended group admin rights and giving access to fully developed new features, including editing web pages on the site. This agreement is designed to respect privacy laws and simplify the implementation of the planned staged development setup.
• It seems like the biggest obstacle in the current system is the wiki lacking support for merges when co-writing. Also the single sign on has been identified as one of the key features requested. Given our limited resources, it might be best if these features were to be actively co-developed with Digia together with the community.

There are a couple of other things currently being worked on, such as cleaning up the CSS, simplifying the site navigation, removing old links, and a walk through of the old bugs in the bug-tracker. This work is currently under way.

Since these processes are being run in parallel with the upkeep and maintenance of qt-project.org site from day to day, it’s a little difficult to give an exact time span on when each step will be implemented. We will give progress updates on the Qt Project malinglist[3].

Please have a look at the references below for more information. We welcome your feedback.

1. http://qt-project.org/wiki/Qt_Project_Web_Open_Governance
2. http://qt-project.org/wiki/Qt_Project_Web_Meeting_Summary
3. http://lists.qt-project.org/mailman/listinfo/web

One of the cool new features of gcc 4.8 is the built in “Address Sanitizer”: a memory error detector for C/C++ that will tell you instantly when you e.g. access already deleted memory. This is actually a Google project from Clang/LLVM, so for LLVM users this might be old stuff, but it wasn’t for me Since documentation on every day use is still a bit scarce on the web, I’m dumping the gist of how to put it to good use here, especially in the Qt context …

How does it work?

It basically overwrites malloc and free, and does check the memory before every access (see the project wiki for the details). Apparently it does that in a very efficient manner, since the slow down is only about 2x compared to uninstrumented execution! Who knows, maybe we can enable it for the Qt-Project CI system at one point?

Be warned though that it only works so far on Linux and Mac. No luck for MinGW

How to enable it?

Since it is part of the compiler suite enabling it is easy: just add -fsanitize=address -fno-omit-frame-pointer to the compiler calls, and -fsanitize=address to the linker calls. Anyhow, to catch issues where the memory is allocated, de-allocated or accessed by Qt you do not only have to instrument your application, but also Qt. There’s a tentative patch for Qt 5.2 which makes this easy:

https://codereview.qt-project.org/#change,43420

It is scheduled for the dev branch (Qt 5.2) because it’s a new feature, but you should be fine cherry-picking it to e.g. Qt 5.0. You can then configure Qt with -address-sanitizer, and run qmake CONFIG+=address_sanitizer for your own applications.

If you don’t want to cherry-pick, you can also pass the additional command line arguments to qmake by explicitly setting QMAKE_CXXFLAGS, QMAKE_CFLAGS, and QMAKE_LFLAGS manually:

$ qmake QMAKE_CXXFLAGS+="-fsanitize=address -fno-omit-frame-pointer" \
QMAKE_CFLAGS+="-fsanitize=address -fno-omit-frame-pointer" \
QMAKE_LFLAGS+="-fsanitize=address"

How to use it?

Just run your application! If you happen to hit a memory issue it will abort, and show you a stack trace with module names and addresses. You will need a separate tool called asan_symbolize.py to get the symbols, and then maybe c++filt to de-mangle the C++ symbols.

Demo!

$ mkdir addresssanitizertest

$ echo "
#include <QDebug>
int main(int, char *[]) {
const char *str = QString("Evil!").toLocal8Bit().constData();
qDebug() << str;
}
" > addresssanitizertest/main.cpp

$ cd addresssanitizertest && qmake -project && qmake CONFIG+=address_sanitizer

…

$ ./addresssanitizertest 2>&1 | asan_symbolize.py | c++filt
=================================================================
==32195== ERROR: AddressSanitizer: heap-use-after-free on address 0x600c0000bcd8 at pc 0x4016ce bp 0x7fff7ccd86c0 sp 0x7fff7ccd86b8
READ of size 1 at 0x600c0000bcd8 thread T0
    #0 0x4016cd in QString::fromUtf8(char const*, int) /home/kkoehne/dev/qt/qt-5.1-gcc-4.8.0-64/qtbase/include/QtCore/../../../../qt-5.1/qtbase/src/corelib/tools/qstring.h:478
    #1 0x401b1e in QDebug::operator<<(char const*) /home/kkoehne/dev/qt/qt-5.1-gcc-4.8.0-64/qtbase/include/QtCore/../../../../qt-5.1/qtbase/src/corelib/io/qdebug.h:117
    #2 0x401282 in main /tmp/addresssanitizertest/main.cpp:6 (discriminator 1)
    #3 0x7fac5c1e3a14 in __libc_start_main ??:?
    #4 0x401118 in _start /home/abuild/rpmbuild/BUILD/glibc-2.17/csu/../sysdeps/x86_64/start.S:123
0x600c0000bcd8 is located 24 bytes inside of 64-byte region [0x600c0000bcc0,0x600c0000bd00)
freed by thread T0 here:
    #0 0x7fac5eab9c5a in __interceptor_free _asan_rtl_
    #1 0x7fac5d353e59 in QArrayData::deallocate(QArrayData*, unsigned long, unsigned long) /home/kkoehne/dev/qt/qt-5.1/qtbase/src/corelib/tools/qarraydata.cpp:125 (discriminator 2)
    #2 0x401c21 in QTypedArrayData::deallocate(QArrayData*) /home/kkoehne/dev/qt/qt-5.1-gcc-4.8.0-64/qtbase/include/QtCore/../../../../qt-5.1/qtbase/src/corelib/tools/qarraydata.h:230
    #3 0x401630 in QByteArray::~QByteArray() /home/kkoehne/dev/qt/qt-5.1-gcc-4.8.0-64/qtbase/include/QtCore/../../../../qt-5.1/qtbase/src/corelib/tools/qbytearray.h:396 (discriminator 1)
    #4 0x401231 in main /tmp/addresssanitizertest/main.cpp:5 (discriminator 1)
    #5 0x7fac5c1e3a14 in __libc_start_main ??:?
previously allocated by thread T0 here:
    #0 0x7fac5eab9e7f in __interceptor_realloc _asan_rtl_
    #1 0x7fac5d35944e in QByteArray::reallocData(unsigned int, QFlags) /home/kkoehne/dev/qt/qt-5.1/qtbase/src/corelib/tools/qbytearray.cpp:1472
    #2 0x7fac5d358d05 in QByteArray::resize(int) /home/kkoehne/dev/qt/qt-5.1/qtbase/src/corelib/tools/qbytearray.cpp:1431
    #3 0x7fac5d77e452 in QUtf8::convertFromUnicode(QChar const*, int, QTextCodec::ConverterState*) /home/kkoehne/dev/qt/qt-5.1/qtbase/src/corelib/codecs/qutfcodec.cpp:130
    #4 0x7fac5d780e91 in QUtf8Codec::convertFromUnicode(QChar const*, int, QTextCodec::ConverterState*) const /home/kkoehne/dev/qt/qt-5.1/qtbase/src/corelib/codecs/qutfcodec.cpp:507
    #5 0x7fac5d77a483 in QTextCodec::fromUnicode(QString const&) const /home/kkoehne/dev/qt/qt-5.1/qtbase/src/corelib/codecs/qtextcodec.cpp:807
    #6 0x7fac5d48dd26 in QString::toLocal8Bit() const /home/kkoehne/dev/qt/qt-5.1/qtbase/src/corelib/tools/qstring.cpp:4020
    #7 0x401215 in main /tmp/addresssanitizertest/main.cpp:5
    #8 0x7fac5c1e3a14 in __libc_start_main ??:?
Shadow bytes around the buggy address:
  0x0c01ffff9740: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c01ffff9750: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c01ffff9760: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c01ffff9770: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c01ffff9780: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c01ffff9790: fa fa fa fa fa fa fa fa fd fd fd[fd]fd fd fd fd
  0x0c01ffff97a0: fa fa fa fa fd fd fd fd fd fd fd fa fa fa fa fa
  0x0c01ffff97b0: 00 00 00 00 00 00 00 fa fa fa fa fa 00 00 00 00
  0x0c01ffff97c0: 00 00 00 fa fa fa fa fa 00 00 00 00 00 00 00 fa
  0x0c01ffff97d0: fa fa fa fa fd fd fd fd fd fd fd fa fa fa fa fa
  0x0c01ffff97e0: 00 00 00 00 00 00 01 fa fa fa fa fa 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:     fa
  Heap righ redzone:     fb
  Freed Heap region:     fd
  Stack left redzone:    f1
  Stack mid redzone:     f2
  Stack right redzone:   f3
  Stack partial redzone: f4
  Stack after return:    f5
  Stack use after scope: f8
  Global redzone:        f9
  Global init order:     f6
  Poisoned by user:      f7
  ASan internal:         fe
==32195== ABORTING

Have fun hunting down memory issues

Update: Apparently a stock gcc 4.8.0 has still issues with address-sanitizer: libasan isn’t linked automatically, an internal compiler error in qtbase … I’m personally using a gcc from 4.8 branch.

Qbs, our alternative build tool, has reached a new mile stone. Since the last one in December, qbs has had the following improvements:

The whole codebase has seen a major overhaul. Experiments from the prototype phase have been removed. The API for the Qt Creator plugin has been stabilized. The test suite has been extended to cover most features. On our internal test farm – the same that is used for Qt Creator – qbs is tested on Linux, OS X and Windows every time the testing infrastructure detects a new change in the repository.

Support for installing your built products has been added. To install your project to ~/foo/bar use

qbs install --install-root ~/foo/bar

The project loading phase got faster. On my machine, the times to generate the makefiles respectively create the build graph for Qt Creator 2.7 look like this:

The running time of incremental null builds, that is determining that nothing of your project has changed, look currently like this for Qt Creator 2.7 (same machine with Windows/Linux dual boot):

The performance gain stems from the fact that qbs only has to check the timestamps of the project’s source files. It already knows the timestamps of generated files from the previous build.
On Windows this approach gains us much more than on Linux because retrieving the file timestamps is so unbelievably slow.

Support for detecting changes of project settings has been improved. Changing properties like cpp.defines will now get noticed and result in a rebuild of the affected products.

Last but not least, Qt Creator 2.7 comes with an experimental Qbs project manager plugin. It provides support for loading and building qbs projects.

QML as a technology has become increasingly important for the success of Qt. It allows for the creation of smooth, animated user interfaces, in line with expectations on the market today. There are three main features, that make it so suitable for UI creation. The first one is the declarative syntax, that makes it extremely easy to create these user interfaces and have both developers and UI designers work on the same code base. Secondly, the technology makes the integration of native code relatively easy, allowing to do much of the application logic and heavy lifting in C++. And finally, the choice of Javascript as an integral part of the QML language allows for easy prototyping and opens the technology up to a wider audience.

The engine as it is today is a fantastic basis and fills most of our users needs. However, it also has a couple of shortcomings and problems that will need to get solved in the future. This series of blogs is going to outline our findings and present the solutions that we are planning to implement for them. The goal will be to get to a better, more flexible and easier to maintain QML engine in the future.

So let’s start of with some of the problems we’re facing with the current engine.

• Several object models
  The current QML engine uses the V8 Javascript engine to execute property bindings. Each QML item has several representations internally. One towards V8 (using the public V8 API), one towards the QML engine, and one to expose it as a QObject to native Qt. The problem here is that this requires the QML engine to keep these different representations in sync, leading to a lot of glue code and rather high memory consumption to hold the different representations.

• Bindings done through JS closures
  Each binding is represented as a JS function closure towards V8. This requires rewriting the expression as a closure, and then letting V8 parse the rewritten expression once again. Evaluating the binding requires calling a JS function in V8 with quite a bit of overhead to instantiate the proper context for executing the binding. This is rather slow and lead to the development of a small expression interpreter (called V4) inside the QML engine that would evaluate simple expressions. This interpreter is many times faster than evaluating through V8.

• Data type conversions
  One reason why evaluation of expressions in V8 is slow is the overhead of converting data types from Qt to V8 and vice versa. Accessing a Qt property would for example create a QVariant, that would then need to be converted to a V8::Value. If the variant was a string this involved copying the string data. To soften this, various caching mechanisms were introduced, but those came at the cost of increased memory usage and additional complexity in the code.

• QML scoping rules
  QML is syntactically a tree of items. Inner items implicitly see properties of outer items leading to a well defined scope chain. Unfortunately this scope chain works differently than traditional Javascript and couldn’t be directly implemented with existing Javascript engines. The only way to do it directly would have been through nesting slow and deprecated with() statements. The current solution involves a very intrusive patch to V8 and still requires all QML properties to be looked up by name.

• Throwing away QML type info
  QML as a language has type information. Javascript however is completely untyped. This lead to the fact that all type information got thrown away at QML compile time. Retaining the type information would allow us to optimise QML expressions a lot better.

• iOS and WinRT support
  iOS does not allow making memory both executable and writable, something that existing JS engines require. WinRT doesn’t allow making memory executable at all. This makes it impossible to use V8 on these platforms without writing a full interpreter backend to V8.

• Working with upstream V8
  As said above, we are currently forced to maintain a rather large and intrusive patch set on top of V8. There is no chance of merging these patches upstream, as V8 fully focuses on the browser use cases.

These different arguments have lead to a research project that was started Roberto Raggi and Aaron Kennedy in Nokia around a year ago, where they explored the feasibility of having a JS engine that is tailored to the use cases QML requires. The project with the codename v4vm was then transferred to Digia, where Simon, Erik and myself took it up and continued with it. It lived as a playground project on qt-project.org for the last couple of months.

Today we integrated this research project into a development branch of Qt Declarative, and we will continue to work on it there from now on.

The new engine contains a fully compliant ECMAScript 5.1 implementation, that runs on all platforms Qt supports. It contains a JIT that currently works on Linux, Mac and iOS. Integration into the current QML engine is currently done through a V8 compatible API layer which we plan to remove in the coming weeks. The engine can run all Qt Quick demos (with some minor glitches).

One of the things to note is that the engine is focused at QML use cases. This implies that we expect QML performance to become a lot better then it is today. Pure JS performance will on the other hand not be quite as good as what you get with V8 as a backend.

Still our current benchmark numbers are very promising also for pure JS code. The V8 benchmark runs currently around three times slower than the JS engine used in Qt 4.8 and Qt Quick 1, and we see a lot of potential for further optimisations.

Details about the new engine and our future plans will come in a followup post. You can find the code in the wip/v4 branch in the qtdeclarative repository. Feel free to play around with it. If you want to join development, feel free to contact us on #qt-v4vm on freenode.

It has been a busy week – today we are releasing Visual Studio Add-in 1.2.1 for Qt 5. This is mainly a bug fix release targeting problems found in previous releases. In addition to bug fixes the Add-In now supports Visual Studio 2012 debugger visualizers for Qt 5 classes. On the commercial version there is also support for Qt Quick.

As before, at least Visual Studio Professional is required to use the Add-in. Supported versions are Visual Studio 2012 (update 2 recommended), 2010 and 2008.

Highlights of Visual Studio Add-In 1.2.1 include:

• Qt Quick project wizard, QML keyword highlighting and QML file preview in the commercial version
• Visual Studio 2012 debugger visualizers for Qt 5 classes
• Possibility to use Qt 4 Add-in and Qt 5 Add-in in same computer (in turns)
• Incorrect Qt 5 library/module names and include paths fixed

You can find the detailed list of changes to the Visual Studio Add-in 1.2.1 in the change log.

Using Qt 5 VS Add-in and Qt 4 VS Add-in together

Qt 4 Visual Studio Add-in is not allowed to run at same time with the Qt 5 Add-in, if found it will be closed. It is however possible to use both Qt 4 and Qt 5 Add-ins in turns. The user must choose Qt-version within the Add-in manager (both can not be active simultaneously). Extra care must be taken to use correct project and class wizards because both Qt 4 and Qt 5 ones are visible if both Add-ins are installed in system.

Qt Quick support in the commercial version

Digia has created additional functionality to the Visual Studio Add-In available only for the commercial licensees of Qt. The commercial version has new Qt Quick2 Application project wizard for creating project that can contain both QML and C++ code. The commercial Add-In also provides keyword highlighting for QML files and new preview feature for launching qmlviewer.

Get it from the Customer Portal of Qt Project Downloads

The new Visual Studio Add-In 1.2.1 is available for both commercial and open-source users. If you hold a valid commercial license, you can download the new Visual Studio Add-In from the Customer Portal. The open-source version can be downloaded from the Qt Project. If you are not a commercial licensee, but want to try out the additional functionality, you can try our the commercial version with our free 30-day evaluation.

I hope you enjoy developing Qt 5 applications with Visual Studio. Please provide us feedback either through the commercial support or via the Qt Project mailing lists.

Qt’s popularity is gaining ground with our friends in China and the surrounding region. We are happy to announce a Qt Developer Day event in China.

Digia together with top sponsors, BlackBerry and Jolla, will host a one-day event with Qt experts and fans coming together to listen and learn about new developments with the best cross-platform application and UI development framework.

Save the date!

- Beijing: June 6

Please have a look at our Chinese blog post for more information.

Today we are releasing Qt 5.0.2 – the second patch release of Qt 5.0 series. I am extremely happy about the interest towards Qt 5 as well as the amount of improvements we have been able to add into the Qt 5.0.2 release. 

Qt 5.0.2 brings over 600 improvements compared to Qt 5.0.1, most of these in order to address the issues Qt users have noted when bringing their applications to Qt 5. As a patch release Qt 5.0.2 does not introduce new functionality, but we have again been able to add some new binary installers, as well as enable some use cases that have been problematic in the earlier Qt 5 releases.

Highlights of Qt 5.0.2 include:

• New binary installers for VS2012 with ANGLE and for VS2010 with OpenGL (for those who do not wish to use ANGLE)
• Creator 2.7.0 included in the release package (Qt 5.0.1 was shipped with Creator 2.6.2)
• Possibility to easily skip modules in configure when building Qt yourself
• Static linking now works correctly for the Qt libraries
• Overall more than 600 improvements in 17 different modules of Qt

For detailed list of changes in Qt 5.0.2, please have a look into the changes file included to each module – or check the most important ones: qtbase, qtdeclarative, qtwebkit and qtmultimedia, as well as Creator 2.7.0 release announcement.

As always, Qt 5.0.2 maintains both forward and backward source compatibility with Qt 5.0. We are continuously ironing out the glitches and improving quality with every new release. If you encounter a problem, please check the known issues page first, where you can find solutions and workarounds for common problems. If you find a previously unknown bug in Qt 5, please help us to improve the product in future releases by reporting it to bugreports.qt-project.org, or contact us via our Customer Portal if you have a commercial license.

Qt 5.0.2 is now tagged in the Qt Project repository. The source packages and installers for Qt 5.0.2 are available for download at qt-project.org/downloads for open-source users, as well as via the Customer Portal for commercial licensees.

Two weeks ago we initiated the Qt 5.1 cycle by merging our development code base into the stable branch. Since then, the release team has been working on stabilizing the branch and we now have the first set of Qt 5.1 packages available. They are available from the new download.qt-project.org area for the open source version and in your customer portal for commercial users). The packages are source only and mainly for people already used to developing with Qt. Unless you feel comfortable compiling Qt on your own, you might want to wait for the beta which will come out within the next few weeks.

A lot has happened since the Qt 5.0 release in December, and I am truly impressed by the amount of new things that we managed to get done for this alpha release. Let’s have a short look at the most important new features.

Android & iOS

To start with, we have added preliminary support for Android and iOS to Qt 5.1. This release is fully usable on both platforms and you can begin to develop for both OSs immediately. All of qtbase (Qt Core, Gui, Network etc.) is implemented. Qt Quick works very nicely on Android and most sensors are supported. There are, however, certain limitations. Some parts of Multimedia are not fully implemented and Qt Quick is not yet working on iOS. Tooling is also still a work in progress, and not everything can be done from within Qt Creator yet, but many things are already  working nicely and smoothly.  As announced last year, full Android and iOS support will come with Qt 5.2, but Qt 5.1 provides a solid base for developers to create full applications for these two platforms.

Introduction of Qt Quick Controls

Then, we finally have cross-platform controls for Qt Quick. The modules ((QtQuick Controls (formerly known as Desktop Components)and Qt Quick Layouts) offer ready- available controls and layouts you can use to build your user interface, starting from buttons, layouts, over menu and toolbars to dialogs and high-level navigational controls. Of course, they have the look and feel of native widgets of the underlying platforms. They are currently implemented for the desktop operating systems, support for touch-based platforms will get added for Qt 5.2.

Add-ons

A couple of new modules got added as well. First of all, we brought back Qt Sensors as an add-on. The module is currently supported on Android, iOS, BlackBerry and Mer (Sailfish). A module for controlling serial ports (Qt SerialPort) has also been added, and we have an X11 specific add-on (Qt X11Extras).

Finally, we have added many other smaller features to the existing modules. For more details, please have a look at the Qt 5.1 feature list.

From now, we will start work on Qt 5.1 beta, which I  expect to be released a few weeks from now. Following that, Qt 5.1 final can be expected to come before the beginning of summer. Let us know what you think of our Qt 5.1 alpha. Enjoy!

I am very pleased that we have already ten mirrors from three continents active for the new download service of the Qt Project, and more are on their way. With the new MirrorBrain based setup is it very easy to become a mirror for Qt – and even more importantly it is seamless for the user to benefit from the nearby mirrors.

We plan to use the new download.qt-project.org service starting from next week for the upcoming releases of Qt 5.0.2, Qt 5.1 Alpha and others. The old CDN service will be available as backup. When a release is made you can see it appear to qt-project.org/download page, so everything stays quite similar as before.

If needed, it is easy to see if the file you are planning to download has already been mirrored by viewing the details in conjunction of each file. The mirrors synchronize content with different schedule, so it takes a while for file to become available in all mirrors after it has been released. We are also looking into leveraging torrents as an additional way of downloading files.

For the commercial Qt licensees there are no changes, as the Customer Portal and distribution systems are separate from the open-source downloads.

I hope we continue to receive more mirrors for Qt Project in the coming weeks. If you are interested in mirroring Qt, see instructions how to become a mirror from the Qt Project wiki. Also, feel free to ask you local mirror providers to start mirroring Qt.

We are happy to announce that the 10th annual Qt Developer Days, the premier Qt event of the year, is booked and confirmed this autumn in Berlin and Silicon Valley. Save the dates!

• Berlin, Germany (Café Moskau and Umspannwerk Alexanderplatz): October 7-9
• San Francisco, CA (The San Francisco Airport Marriott Waterfront): November 6-8

Just like in 2012, Digia will be a co-host together with KDAB and ICS for the Berlin and Silicon Valley events respectively. Qt Developer Days 2012 was a fantastic event where Qt got a mega boost from the very-well received keynote by Digia SVP, Tommi Laitinen and also from the hundreds of enthusiastic Qt fans on site. It was an amazing opportunity to hear from the Qt experts first hand, network with new and veteran Qt groupies and learn about the bright future ahead for the best cross-platform development framework.

Last year’s event would not have been possible without the planning and execution by KDAB and ICS. They did an awesome job and brought the community together to give a positive signal that Qt was alive and kicking.

In case you missed last year’s event or you are just feeling nostalgic, have a look at the following videos courtesy of KDAB and ICS.

Qt Developer Days 2012 Berlin

 Qt Developer Days 2012 North America

Now, as we are a quarter of the way through 2013, we are excited that this year will mark a decade of Qt Developer Days. Time flies while having fun. Mark your calendars and make all efforts possible to join us and the army of Qt developers that will gather at both events. These are the events to be at to hear from our Qt experts on the latest developments on Qt and upcoming ports, the roadmap, best practiceson fascinating features and functions and lastly the best places to be at to get your jabber on and network with the Qt community.

We will soon post a call for papers, so stay tuned! http://www.qtdeveloperdays.com.

Anybody been to all 9 developer days? Who is shooting for 10? See you there!

The Qt Project is currently using a content delivery network based solution for distribution of releases. We have been working to improve distribution of Qt open-source packages and now have the setup available for mirroring. Now we need to get more mirrors before going to production.

The idea is to switch to MirrorBrain based system and away from the current content delivery network based service. The work was started a while ago by Daniel Molkentin and now we have the setup available for mirroring. It is very much similar to what KDE is already using, so for many it is quite familiar. At this point I would like to thank Danimo and others from KDE for all the help provided to enable this.

The system is not yet taken into production use, we need to first have enough mirrors in place. Downloads from the new service work, but the system is not yet up to handle the needed load. Currently we have two mirrors in place, and need more before the new download service can be taken into production use.

• You can find the new download service from http://download.qt-project.org
• Information on how to become a mirror is in the Qt Project wiki at http://qt-project.org/wiki/mirror_howto

The new service is for open-source content only. All the commercial Qt licensees are using a separate system. So it is completely ok for non-profit organizations to become a mirror for Qt Project.

If your organization is willing to become a mirror, please follow the steps in the wiki. Or if you know some organization who already provides mirrors, please ask them to become a mirror for the Qt Project.

We are keenly waiting to get the new download service active as it allows much more flexibility than the current setup. Getting the new system into production is also a prerequisite for providing the new online SDK for the Qt Project.

Thus far, the Qt Installer Framework has been used to create Qt SDK Installers. You can now use it also to create installers for your own applications. This is why we decided to make a formal release for the first time as opposed to just tagging a Git version. Therefore we are offering binary downloads for the major platforms at https://releases.qt-project.org/qt-installer-framework/1.3.0/.

The recent months were mostly used for stabilization, cleanup work and improving the documentation. But in the 14 months since 1.2 some new features were introduced as well.

Notable new features include the possibility to translate the installer (German and Russian translation are included). The included 7zip library was updated to the current version. The Installer Framework was made compatible with Qt 5 (and continues to work with Qt 4 of course). For online installers, repositories using https are now supported in addition to http.

Notable contributions are the Russian translation by Ivan Komissarov and Support for the BB10 SDK by Andreas Holzammer. Thank you!

The Qt Charts 1.2.1 is a patch-level release containing 9 fixes which are listed in the README file included in the source package. We are currently working on the next release, which brings Polar and Box Plot charts and some API enhancements suggested by charts users.

For an overview of the Charts functionality, please refer to the Charts product page and the latest new features are listed in the 1.2.0 release announcement.

We have made the Charts 1.2.1 release available to commercial Qt licensees through the Qt Customer Portal. The release team is working on a new SDK and therefore the Charts is not yet available through there yet. Stay tuned.

If you don’t have a commercial license for Qt, you can test out the Charts 1.2.1 by downloading a 30-day free evaluation. Let us know what you think!

We are happy to announce the Qt Creator 2.7.0 release today, which comes with loads of new features, improvements and bug fixes.

C++ support in Qt Creator got even more improvements for C++11, like handling of alignof, alignas and noexcept, brace initializers, and more lambda fixes. Also, if Qt Creator cannot find out if your tool chain expects C++11 or C++98/03, it defaults to C++11 now, for a better out of the box experience. Also there are improvements on the refactoring actions side, for example quick fixes for adding getters and setters for class members, and for adding the getters and setters that are specified in a Q_PROPERTY.

QML support got lots of fixes for Qt Quick 2 in the code editor, and there was a lot of work done to make Qt Quick Designer work with Qt Quick 2. Please note though that the Qt Creator standalone binary packages are based on Qt 4 and do not provide the necessary Qt Quick 2 based external worker tool (which of course needs to be built with Qt 5). For now you either need to compile Qt Creator with Qt 5 yourself, or at least compile the qml2puppet yourself with Qt 5 (qt-creator/share/qtcreator/qml/qmlpuppet/qml2puppet) and put that into qtbase/bin of your Qt 5 install (and make sure that your project uses a Kit that uses that Qt version). Or you wait for Qt 5.0.2 packages that will contain a Qt 5 based build of Qt Creator again.

On the BlackBerry support side, we got a new settings page, which allows to easily generate Kits (and the necessary Qt version and compiler information) from an NDK path, and helps users with registering and generating developer certificates and other files that are needed for uploading apps to their devices. Also the editor for bar descriptor files, which define application appearance and behavior, can now be switched between editing the pure XML and a graphical editor. There were many other improvements as well, for example regarding debugging on devices.

Experimental support for the (also experimental) QBS build tool was added to Qt Creator, and the binary packages now also contain it (in contrast to the prereleases), though it is disabled by default. To enable it, open “Help > About Plugins” (on Mac it’s in “Qt Creator > About Plugins”), tick the QbsProjectManager, and restart Qt Creator, no further downloads/installations are necessary. The Qt Creator sources themselves also come with QBS project files, if you were wondering which project you can open with it now . If you want to build Qt Creator with QBS support yourself, you first need to pull in its sources: Qt Creator’s git repository now has QBS as a submodule, so “git submodule update –init && qmake -r && make” in the top-level directory of your git checkout should be all you need to do.

Of course this is only a very small part of the actual improvements that were done, but talking about all of them – Debugging, Android, VCS, FakeVim, just to mention a few – would be beyond the scope of the blog post. Even bookmarks got some love this time, thanks Vasiliy Sorokin . If you want to know more about changes in this version, you might want to have a look at our change log.

Open source download: Qt Creator downloads page (or the Qt Project downloads front page)

Qt Commercial customers find packages in the Customer Portal

Important note for developers for Madde: Madde support has been disabled by default in Qt Creator 2.7. Most functionality is available by default through the “generic Linux” support. If you still want to use the Madde specific plugin, you need to enable it: On first start of Qt Creator 2.7.0, run it with command line argument “-load Madde” (that is important, otherwise you will lose existing Madde settings like tool chains and Qt versions), then open Help > About Plugins and enable the Madde plugin.

Important note for people that turned off the QmlJSTools plugin manually: Qt4ProjectManager depends on it in Qt Creator 2.7, so you need to turn it on again to be able to open qmake projects.

The first commit in the effort to port Qt 4 to Android was on Christmas Day, 2009: “Android mkspecs and semaphore” by BogDan Vatra.

On January 22nd, 2010, he committed “A small step for Qt, a giant leap for android” with a working graphics system plugin and could actually run Qt applications on an Android device. He uploaded a video to celebrate.

On February 20th, 2011, he announced the first usable release of Qt 4 for Android, under the moniker of Necessitas.

For the past 3+ years, BogDan and others have been (and are still) developing Necessitas on their spare-time, and on November 8th, last year, BogDan agreed to take his work into Qt 5 and submit the port to the Qt Project.

He pushed the first version of Qt 5 for Android to a WIP branch on January 4th, and recently we integrated into the “dev” branch, meaning that it will become part of Qt 5.1 when it is released.

For this preliminary release, we are focusing on the developer experience, working to enable Qt developers to easily run and test their applications on Android devices. While there’s nothing preventing you from deploying your app to an app store with Qt 5.1, we’re recommending that people wait until Qt 5.2 before they do that, as we’d like to put some more work into improving that experience: Making more options for how your app is deployed, adding more polish in general, and adding more support for Android APIs, both by allowing you to extend your app with Java code or by mapping them in C++ APIs, whichever makes the most sense.

On to the demos!

To start off, here’s a video of the Qt 5 Cinematic Experience demo running on (from left to right): a Nexus 4, an Asus Transformer Pad TF300T and a Nexus 7. The Cinematic Experience demo has quickly become our demo of choice at events, because it nicely shows a lot of the new graphical capabilities in Qt Quick 2, such as shader effects, particle effects, the new PathAnimation as well as the hardware-accelerated SceneGraph architecture underneath, which makes it possible to run all this at 60 fps.

In addition to the core parts of Qt, we also support the QML media player APIs in QtMultimedia. Here’s a nice video player written by Andy in QML, with fragment shader effects on top of the video, running on an Asus Transformer TF300:

To show off multi-touch support, here’s a simple hand painting demo running on a Nexus 4. This also shows the support for native menus:

The lowest Android API level supported by Qt 5 is API level 10, aka Android version 2.3.3. This means we can also have Qt apps running on reasonably priced devices, such as this Huawei Y100:

Here’s the overview of what we have right now:

• Support for creating Qt Widgets and Qt Quick apps that run on Android devices.
• Support for Android API level 10 (version 2.3.3) and up.
• QML media player functionality in QtMultimedia.
• A set of commonly used sensors in QtSensors.
• Cross-platform features of Qt of course (including Qt Quick controls and QtGraphicalEffects.)
• Developing and configuring apps in Qt Creator 2.7.
• Deploying a test build to a device directly from Qt Creator.

In addition, we plan to soon support the possibility of distributing the Qt libraries through the Ministro distribution tool, which allows you to share a set of Qt libraries across several apps on a device, and which will be the primary way of deploying apps with Qt 5.1. Other than that, this is all already available: Just check out the wikifor instructions. Let us know if anything goes horribly wrong. We can usually be found in the #necessitas channel on the Freenode IRC servers.

What’s next, you ask? You can in fact help us decide! Both by reporting your bug findings and feature expectations to us, and by contributing your code. We will be working steadily on improving Qt 5 for Android, and would benefit greatly from your feedback. In the wiki, we are also compiling a list of devices where Qt has been verified to run. If you take the time to add devices you have tested to the list there (as well as any issues you have found), it would very much be appreciated

Finally: A big thanks to BogDan Vatra, Ray Donnelly and everyone else who has been contributing to the Necessitas project for the past years, as well as Qt 5 for Android in the past months. And thanks to everyone who will contribute in the future.

This is the 3rd annual Qt Contributors Summit and it will be the biggest summit to date due to our joined forces with the KDE Akademy conference. More than 500 contributors are expected and it’s solely dependent on sponsorship to succeed.

This will foster interaction, knowledge transfer and technical progress in a highly-productive atmosphere where new and veteran contributors can meet to influence the future direction of Qt. The key benefits of sponsoring the joint Qt CS and KDE Akademy conference are:

• Meeting key Qt and KDE contributors. There will be 500 upstream and downstream developers and key maintainers, making Qt the top-ranked cross platform framework in developer satisfaction[1].

• Influence how Qt will be developed in the future. Besides the Qt community, there will be many other free software projects and businesses participating in the joint Qt Contributor Summit and KDE Akademy conference.

• Be visible. A sponsorship gives you valuable promotional possibilities such as visible advertising, prominent talks and international press coverage.

Digia is a confirmed top platinum sponsor of this year’s combined event and we need even more sponsors to make sure that this year’s event is successful.

Sponsorship Options

This year’s event is providing individuals and companies two ways to sponsor – both which come with many valuable promo benefits:

1. Single sponsorship: Qt Contributors Summit, 15-16 July
2. Joint event sponsorship: Qt Contributors Summit and KDE Akademy, 13-19 July

For the Qt Contributor Summit, the sponsorship packages range from Small to XL where sponsors are able to showcase their Qt commitment in front of a knowledgeable, enthusiastic and motivated ecosystem via a variety of sponsor benefits solidifying their stance as active contributors and advocates of the Qt technology.

1. The single Qt CS sponsorship packages and the combined Qt CS and KDE Akademy sponsorship packages in detail

Practical information

Please contact Knut Yrvin at Digia, Qt or Claudia Rauch at KDE, if you would like to receive more information on sponsorship of the Qt Contributors Summit and/or the KDE Akademy conference. Please contact us by this e-mail form.

1. The report: Cross Platform Tools 2012 by VisionMobile surveying 2,400 developers.

Today we published the Qt Creator 2.7.0 release candidate. Since the set of features is the same as for the beta release of course, I’ll just point you to the blog post by André about that, who summarized it quite nicely.  But of course we sat down and fixed lots of bugs, summing up to a total of 490 changes. Thanks to all who helped by testing, reporting bugs, debugging and actually fixing!

Just to mention a few things: There were lots of fixes to the C++ code model again,  with one fix that almost is a sneaked in feature: The C++ quick fix “Add Definition” now also works for non-member functions. Android support got some polish, like fixing kits when the used NDK changes. The kits received some more love in general, with around 30 fixes alone in the area of tool chains, Qt versions, devices and kit setup. On the debugger front, it’s for example now possible to use mini dumps on Windows. And Leena fixed the documentation all over the place, as always many thanks to her!

Users of the open source version of Qt Creator should jump over to the Qt Project downloads page, commercial customers find their packages in the Customer Portal.

Important note for developers for Madde: Madde support has been disabled by default in Qt Creator 2.7. If you still want to use it, you need to enable it, first run Qt Creator with command line argument “-load Madde” (that is important, otherwise you will lose existing Madde settings like tool chains and Qt versions), then open Help > About Plugins and enable the Madde plugin.

We are very excited to be able to bring Qt to a new platform. Qt for iOS is planned to be a supported part of Qt 5.2, scheduled for release late 2013. The scope of that release is not completely determined: available resources, platform/app store restrictions and Qt legacy set constraints on the project. This blog outlines the current plan.

Qt 5.1 will contain a preview – which was in fact merged last Friday. It’s also possible to take a look today by checking out the Qt source code. See “Getting Started” for detailed instructions below.

Development and Deployment
Development and especially deployment is done using Xcode. The supported workflow is to maintain a .pro file based project, export it to Xcode (and re-export when the project setup changes), and then build and deploy using Xcode. Source code editing can as usual be done in any editor.

Qt 5 Architecture
Understanding the level of support various Qt modules will get, requires a brief detour into Qt 5 architecture. With Qt 5 there is now a common API that all platforms implement (the Qt platform abstraction – QPA). Most of the Qt for iOS project work will happen here, and this is the code base the team will support. The QPA layer powers both widgets and QML (1 and 2).

Styling
The Qt Mac style uses the HITheme API provided by OS X to draw native-looking UI elements. There is no such API on iOS, which means creating a QiOSStyle similar to QMacStyle is not possible. Cross-platform styles such as the new Fusion style will however be available. Future styling efforts will focus on controls for Qt Quick 2.

Qt Quick 2: JavaScript engines and JIT
Qt Quick 2 uses the V8 javascript engine, which cannot be deployed on iOS due to policy and technical limitations related to V8′s use of a just-in-time compiler. This means no Qt Quick 2 on iOS for the time being. We are aware of the problem and are working on a solution.

What works today

• Widgets
• Graphics View
• Qt Quick 1

• OpenGL
• Touch events
• Orientation events
• ++

Qt5 Cinematic Experience by QUIt Coding, ported to Qt Quick 1 and running on an iPad

Getting started

1. Homework: Setup Xcode for development (acquire certificates, configure devices). Test-deploy one of the standard Xcode app templates. Make sure you have Git installed.
2. Clone qtbase
   git clone git://gitorious.org/qt/qtbase.git qtbase-ios
cd qtbase-ios/
git checkout dev
   [Optional: git checkout ios for the development branch]
3. Build QtBase for either device or simulator. Note that unlike Qt 4, Qt 5 does not support multi-architecture builds.
   /configure -xplatform unsupported/macx-ios-clang -developer-build -nomake examples -nomake tests -release [-sdk iphonesimulator]
make
4. Get the Simple Demo:
   git clone git://github.com/msorvig/qt-ios-demo.git
cd qt-ios-demo
../qtbase-ios/bin/qmake
open qt-ios-demo.xcodeproj

Update: Building Qt Quick 1
You need the full Qt source code, see Building Qt 5 from Git. Then build the QtScript and QtQuick1 modules:

cd qtscript; ../qtbase/bin/qmake; make; cd ..
cd qtquick1; ../qtbase/bin/qmake; make; cd ..