Qt + CMake + code coverage

Yesterday I was working on getting reports on code coverage for Injeqt library. I've found several tutorials on the internet, but every one of them was missing a detail or two.

So here is what I've come with:

1. Update compiler and linker flags in CMakeLists.txt file of your tests:

set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall -W -g
-fprofile-arcs -ftest-coverage -O0")
-fprofile-arcs -ftest-coverage -O0")
-fprofile-arcs -ftest-coverage -O0")
2. Link each test with gcov library:
target_link_libraries (test-target-name gcov)
3. Add new target for extracting coverage data:
add_custom_target (coverage
4. Insert coverage.sh script into directory of CMakeLists.txt:

lcov --capture --directory . --output-file coverage.info
lcov --directory . --output-file coverage.info \
--remove coverage.info "/usr/*" "*.moc" "test/*"
genhtml coverage.info
First lcov invocation will capture all data from previously executed tests. Second will remove useless data like coverage of generated moc files or of standard library headers and tests themselves.

5. Run tests and coverage:
make test
make coverage
6. Enjoy nice HTML coverage report.

Injeqt got 90,4% of lines coverage on first try! I hope to make it even better today.

KDAB contributions to Qt 5.4: qmllint

One type of bug I see very often comes down to syntax errors in QML and JavaScript files. Most of the time these errors are simple typos; however, they creep in, go unnoticed by continuous integration and sometimes reach production — especially on delayed loaded components.

I like fixing bugs, but what I love even more is not fixing them, so I wrote a command line tool that can easily be integrated into our CI system so we can nip them in the bud at build time.

Enter qmllint: a command line QML syntax checker. Example usage:

$ qmllint ClickableImage.qml
ClickableImage.qml:17 : Expected token `numeric literal'

Verifying all files:

$ find -type f -name \*qml -exec qmllint \{\} +
./qml/SettingsPage.qml:35: Unexpected token `if'
./qml/AboutPage.qml:35: Expected a qualified name id

qmllint comes with Qt 5.4 and lives alongside other Qt tools.

Furthermore, I would also recommend using other linter tools in your project, such as json_verify or xmllint. Do not do manually what could be automated by the build system!


qmllint cannot catch semantic errors. There are cases where QML files are syntactically correct but have other types of problems:

Bar.qml:1 TypeFoo is not a type
Bar.qml:2 module "QtQuickControls" is not installed
Bar.qml:6:9: QML Rectangle: Cannot anchor to an item that isn't a parent or

There are no plans on my part to make this tool smarter, I like the “do one thing and do it well” philosophy, so it is finished. Checking for these kinds of mistakes is also very difficult, f.i. because we would need to depend on the QML context of a running application.

But don’t worry, my next blog post will address automating semantic validation, so stay tuned!

The post KDAB contributions to Qt 5.4: qmllint appeared first on KDAB.

Say hello to the first Qt Champion!

QtChampion_logo_72dpi_RGB_colorLast week our first Qt Champion was awarded his title in Berlin at the Qt Developer Days Europe. Samuel Gaist (SGaist on the forums) is now a Community Builder Qt Champion.

If you have visited the Qt Forums you probably have seen Samuels answer to some question. He is, and has long been, the most active contributor on the Forums, topping the most active contributors list week after week.

Aside from Samuels sheer amount of activity on the forums, his other distinguishing feature is his positive attitude to all questions. He sees the positive wibe as a feature of the community and wants to keep the positive energy flowing by contributing himself. in Qt people are willing to help each other with questions and problems, so it is one form of giving back.

Samuel had heard of Qt as he had used Linux and the KDE desktop about ten years ago, but he learned about Qt properly during his studies at the “HES-SO Valais Wallis” school. At the start of 2012 Samuel joined the Qt project forums and hasn’t looked back since.

The biggest Qt project Samuel has up-to-date worked on has been the AgiScan film scanning software, which he worked on at Edeltech Ltd. He also did a talk at the Qt Developer Days Europe 2014 about his experiences on the project.

SgaistIn the last year or so Samuel has also started contributing code to Qt. It all sterted with a question on the forums about a bug in QFileDialog on Mac OS X. Samuel figured he could actually fix the bug and went ahead and answered the question and fixed the bug. From then on Samuel has taken to occasionally looking at the Qt bug reporting system and finding places where he can help, like bug fixing, documentation updates and code cleanups. Lately Samuel has also done some feature work with help from other contributors.

Samuel has found that the diverse background of people involved in the Qt project makes for good discussions, be it on the forums, contribution reviews or the mailing lists. Talking and getting feedback makes for better contrbutions.

In addition to the nice cap and t-shirt, Samuel will be receiving a Qt Professional license for the next year.

Please join me in congratulating our first Qt Champion, Samuel Gaist!

Qt 5.4 Beta Available

I am extremely happy to announce that Qt 5.4 Beta is now available for download. There are a lot of new and interesting things in Qt 5.4 and I will try to summarize the most important highlights in this blog post.

Powerful Web Offering with Qt WebEngine

As the importance of HTML5 has grown we want to provide the best support for HTML5 within the Qt technology offering. The Qt WebEngine, a long-term R&D project based on the Chromium web engine has now reached fully supported version on desktop and embedded platforms.

Qt WebEngine provides a convenient API for both Qt Widgets and Qt Quick for using the Chromium web engine. Besides plain web viewing purposes Qt WebEngine takes full benefit of the whole Qt graphics stack integration allowing you to mix and overlay native Qt controls with web contents and OpenGL shaders. Of course, the fact that Qt provides a full application framework around the web engine makes Qt WebEngine truly an unparalled web engine API.

The new Qt WebChannel module acts as the bridge between QML/C++ and HTML/JavaScript allowing you to expose QObjects into the web context.

For platforms that do not allow distribution of Qt WebEngine as well as use cases where a full-blown web engine is not needed Qt 5.4 will introduce a technology preview of a new module called Qt WebView. It supports embedding the native web engines of the underlying operating system into Qt, and is currently available for Android and iOS. Because of this, Qt WebView also gives a convenient light-weight solution for simple web document integration. Qt WebView will be available with Qt 5.4 final as a separate add-on.

Qt 5.4 also contains Qt WebKit. It is still supported, but as of Qt 5.4 we consider it done, so no new functionality will be added to it. We are also planning to deprecate Qt WebKit in future releases, as the new Qt WebEngine provides what is needed. In most use cases, migrating from Qt WebKit to Qt WebEngine is rather straightforward.

Complete Support for Windows Runtime – Use Qt for Windows Store Apps

The Windows Runtime port of Qt saw its first supported beta release with Qt 5.3. With all the feedback we have improved the port a lot and implemented most of the missing APIs. With Qt 5.4 WinRT is now fully supported as a primary deployment platform.

Qt 5.4 provides support for most of the Qt functionality on WinRT, including for example Qt Quick and Qt Quick Controls, Qt Quick Compiler, Multimedia, Positioning, Network (also SSL/TLS), Core and GUI. With Qt for WinRT port you are now able to target Windows Store Apps: Windows Phone 8.1 and above and Windows tablets with the Modern UI and publish your applications in the Windows Store.

New License Terms – Introducing LGPLv3

As announced earlier, the open-source version for Qt 5.4 is also made available under the LGPLv3 license. The new licensing option allows us at The Qt Company to introduce more value-add components for the whole Qt ecosystem without making compromises on the business side.

Through this dual-licensing model, with Qt 5.4 timeframe we are introducing technology previews for the light-weight cross-platform WebView and the 3D Canvas. Similarly the new Qt WebEngine and Android style are available only through a commercial Qt license and under GPL and LGPLv3 for the open-source users.

To find out the best licensing option for you, please see the new licensing page and the downloads page.

HighDPI Support, Dynamic GL and Other Improvements for Windows Users

In addition to WinRT, Qt 5.4 brings many other improvements to Windows users. Qt 5.4 brings support for High DPI displays. A typical 4K monitor may have 3840×2160 pixels, a logical resolution of 192 DPI, whereas older monitors have around 1920×1080 pixels at 96 DPI. Qt maintains the font point size on a 4K monitor, resulting the text being drawn as indented for a 96 DPI layout. With Qt 5.4 we have especially worked for enabling the HighDPI support for Windows – in addition to improving it in other platforms such as Mac and X11.

HighDPI support is still considered experimental in Qt 5.4, and needs to be enabled via an environment variable. If you are interested in the HighDPI support, check out the overview documentation.

Qt 5.4 brings capability to dynamically select during the application startup whether to use ANGLE or OpenGL on Windows. It is possible to use either opengl32.dll or ANGLE’s OpenGL ES 2.0 implementation in Qt applications without the need for two separate builds of the binaries. This significantly simplifies the task of creating Qt Quick applications for Windows PCs. Dynamic GL switching is not yet enabled in the prebuilt Qt 5.4 Beta binaries. In addition to these, there is a large number of smaller improvements and bug fixes for the Windows port in Qt 5.4.

Other Graphics Improvements

There are quite many important graphics improvements in Qt 5.4 in addition to improved HighDPI support and dynamic GL switching on Windows. One of the most important ones is QOpenGLWidget, the modern replacement for the old QGLWidget class from Qt 4. QOpenGLWidget is a new widget for showing OpenGL rendered content, which can be used like any other QWidget. This also allows us to deprecate old Qt OpenGL module, as everything it does and more is now provided by the other modules.

Qt 5.4 also brings new QQuickRenderControl API, which allows efficient rendering of Qt Quick 2 scenes into framebuffer objects. The contents can then be used in arbitrary ways in Qt-based or 3rd party OpenGL renderers. With Qt 5.4 you can also adopt and wrap existing OpenGL contexts in QOpenGLContext. This improves the ability to embed Qt content for use in other rendering engines. In addition to other new graphics APIs Qt 5.4 brings convenient QOpenGLWindow and QRasterWindow classes as well as introduces support for 10-bit per color channel images.

QOpenGLContext is now able to adopt existing native contexts (EGL, GLX, …). This allows interoperability between Qt and other frameworks, such as game engines. Read more from this blog post.

Bluetooth Low Energy

Qt 5.4 provides a technology preview implementation of Bluetooth Low Energy, which allows communication to a lot of smart sensors and gadgets such as wearables. It is initially supported for BlueZ 4 and 5 on Linux only – support for platforms such as iOS and Android will be added in upcoming Qt versions. With Qt 5.4 we implement the BTLE central role as per Bluetooth spec 4.0, i.e. at the moment you can only create the client for BTLE.

If you are interested in BTLE, please check the Qt Bluetooth LE Overview. We are very much interested in receiving feedback from users to be able to move beyond tech preview state.

Faster Startup, Smaller Deployment Packages and Native Style for Android

We have worked actively to improve support for Qt on Android and there are many important new Android specific items in Qt 5.4. There is now support for QML import scanner, which helps in optimizing the package size for deployment. With the pre-generated assets cache that improves application start-up time introduced in Qt 5.3 and the Qt Quick Compiler available in the commercial editions, it is possible to start Qt for Android applications in a breeze.

On the user interface side we have extended the styling capabilities of Qt Quick and added support to Android style, which enables native look for Widgets and the Qt Quick Controls on Android. In previous versions of Qt it was possible to style Widgets to look native on Android only if one used Ministro. Now both the Widgets and Qt Quick Controls, i.e. buttons, sliders, progress bars and other controls and widgets you use in your application, will look native on Android by default.

iOS Improvements

Support for iOS is improved with Qt 5.4 which contains many important fixes for iOS 8 and Xcode 6. In addition to smaller improvements and bug fixes there are also some new features such as a touch-based text selection model. Instead of the previous desktop like approach (press-and-drag), you can now do press-and-hold to select text. Qt will give you selection handles that can be dragged and a popup text edit menu, like with native apps. The edit menu can also be customized from Qt Quick controls.

Work has also been started to improve usage of native menus in general. In addition to the edit menu mentioned above, Qt 5.4 now uses a native pickerview menu for many of the Qt Quick Controls that have a menu attached. A lot of work has also gone into improving and stabilizing code that deals with window, screen and orientation geometry, and virtual keyboard management.

Support for Mac OS X 10.10, Code Signing and other Mac Improvements

Our Mac users get greatly improved support for new Mac OS X 10.10 Yosemite with Qt 5.4. We have worked hard to improve and fix styling and other issues with Mac OS X 10.10 for Qt 5.4. Applications created with earlier Qt versions work on the upcoming Mac OS X 10.10, but there may be some issues in styling depending on your application. In addition to OS X 10.10 support we have fixed many customer reported Mac bugs in Qt 5.4 Beta – and we continue to provide more fixes still before the final is out.

One very important improvement in Qt 5.4 is support to new code signing style required by OS X 10.10 (and 10.9.5) for applications published in the Mac AppStore. These are still partially work in progress, but the initial support is included already to the Qt 5.4 beta release and polished for the Qt 5.4.0 final release.

Wacom tablets, Wayland, Updated Qt Creator and Other Items

Support for Wacom tablets has been improved and unified across platforms in Qt 5.4 with the help and support by KDE/Krita developers. QTabletEvent now has information about which stylus buttons are pressed, rotation and tangentialPressure have consistent ranges across platforms and proximity events include the type of stylus or other tool in use. With these changes there is one less obstacle to upgrade to Qt 5.

Qt 5.4 now includes the Qt Wayland module. This enables you to run Qt applications on Weston, the reference compositor for Wayland. Weston and Wayland support is still in its early stages, and does not yet provide a full featured desktop environment that you get with Windows, Cocoa and xcb. However, Weston and Wayland already provide a light-weight windowing system that might be desirable to use in the embedded space. Qt Wayland module is delivered as source code only. We will continue our focus on improving our support for Wayland in Qt especially for device creation.

Qt 5.4 Beta packages include the updated Qt Creator 3.2.2 providing improvements for example to Xcode 6 and iOS Simulator usage.

I have listed some of the highlights of Qt 5.4, but many things are not mentioned. For more details, please check What is new with Qt 5.4 – or take Qt 5.4 Beta for a spin and see for yourself.

Get Qt 5.4 Beta Today

Qt 5.4 Beta is now available, for existing Qt users, through your Qt Account, or from the Qt Project download server for open-source packages. Please download, try it out and send us feedback through the mailing lists or bug reports.

Update on the qt.io website work

Hello, some news from the new qt.io website work we are doing.

First, thank you to everyone who provided feedback on the new qt.io site, we appreciate all the comments we have gotten on different channels. And while every comment will not make it as a change to the site, we do evaluate every single one of them and see if something needs to be tweaked.

Please don’t expect instant changes, we have a pretty long backlog including big items like: “How do we solve the problem of using a unified Qt account for logging into all the services we provide on the web?” A bit of patience on your part is appreciated.

That said, the documentation pages are next on the list of things moving to qt.io. One target of moving the documentation is to bring all the open source and commercial documentation under one landing page. That means that you will find all relevant documentation from one location, no more jumping between two sites.

During the documentation move, we will be retiring the docnotes feature on qt-project.org. While there have been some very high quality notes from the community, the feature has mostly gone unused. The effort to maintain the docnotes feature is not worth the benefit that it brings.

One thing we have on the list of things that could be simplified, is contributing to documentation. The issue with contributing to the documentation is that the documentation is built from the Qt source itself, thus any changes to the documentation need to go through the same process as code contributions. And the contribution process might seem a bit complicated to people who are not familiar with it. We haven’t figured out how to best do this, so it’s still in the backlog. If you have ideas on how we could make contributing to the docs easier we would appreciate if you shared them with us.

The schedule for the documentation page moves to their new home on qt.io is before the Qt 5.4.0 release.

We will also be moving all downloads to qt.io with the same schedule as the documentation. The upcoming Qt 5.4 beta will be available on both the qt.io and qt-project.org sites, but now that the qt.io download page has been updated based on the feedback we got (thank you!) we hope that you already move over there for the downloads.

The wiki will be moving over to qt.io after the documentation and downloads as well. The new wiki will be a MediaWiki instance. With the wiki, the biggest amount of work is not setting up the new wiki, but rather moving the content over to the new wiki. We have a lot of external links coming into the wiki, and we need to have pointers to the new wiki from the current one. A rough estimate is that we need to move between three and five hundred pages to get decent coverage in the new wiki. To do this we will be asking for your help in copying content over and marking pages as moved. But more on that in another post later when we have the new wiki up and running.

As for the forums, those are on the list after the wiki. No fixed schedule for that yet, as we need to figure out how to move the almost 50 000 discussion threads we have on the forums.

We’ll be making more posts on how the site move is going as work progresses here.

Removal of the Ubuntu-Touch code from Trojita git

Some of the recent releases of Trojitá, a fast Qt e-mail client, mentioned an ongoing work towards bringing the application to the Ubuntu Touch platform. It turns out that this won't be happening.

The developers who were working on the Ubuntu Touch UI decided that they would prefer to end working with upstream and instead focus on a standalone long-term fork of Trojitá called Dekko. The fork lives within the Launchpad ecosystem and we agreed that there's no point in keeping unmaintained and dead code in our repository anymore -- hence it's being removed.

Qt 5.3.2 Update for Device Creation

For creating devices with Qt, we offer a whole toolkit consisting of Qt libraries, pre-built but customizable software stack (Boot to Qt), value-add components and full embedded tooling around the Qt Creator IDE.

Now, It’s time to update our offering by updating the pre-built Boot to Qt software stack with the latest Qt 5.3.2 and upgrade some of the provided value-add components. Also Qt Creator IDE has been updated since our last update. To read more about the whole toolkit for creating devices with Qt see the documentation overview.

Qt 5.3.2 packs a bunch of bug fixes and improvements to functionality based on feedback and reports we have received. Qt 5.3.2 maintains backward and forward compatibility, both source and binary, with Qt 5.3.0 and the latest, 5.3.1, which was released this June. See more from the Qt 5.3.2 release blog post.

Many of our value-add components have been updated as well. The Qt Quick Compiler has gotten it’s first update, Qt Quick Enterprise Controls have been improved by adding the frequently requested Tumbler control and the Qt Virtual Keyboard is now updated to version 1.2 that provides new layouts and features.

Qt Creator IDE has also been updated with a patch release to version 3.2.2. The Qt Creator 3.2.2 patch release contains a few essential fixes for the embedded functionality on top of fixes provided by the Qt Creator 3.2.1 update from about a month ago.

Qt Virtual Keyboard 1.2

The initial version of the Qt Virtual Keyboard was introduced early this year, and version 1.1 before summer. It is a great choice if you are in need of an extendable virtual keyboard on your embedded device, or as part of your embedded application.

It now has no less than 16 different language layouts to choose from: English, German, French, Spanish, Italian, Russian, Portugese, Polish, Finnish, Swedish, Chinese (pinyin) and Arabic were already in place, and now Hindi, Persian/Farsi, Danish and Norwegian (finally!) have been added. You can of course add more yourself. Next up on our roadmap are Japanese and Korean.

The keyboard supports both 5 and 2-way navigation, so you can also enter text through limited input devices, such as scroll wheel or joystick. As you have seen with previous versions, you can change the look of the keyboard, and now it is in addition possible to switch themes during runtime. For now it is only officially supported on embedded Linux,  embedded Android, and desktop Linux, but Windows support is coming up too. The documentation provides more details.

Qt Quick Enterprise Controls 1.2

Finally, the Tumbler is here! The Tumbler control is well-known in mobile user interfaces and much used in all kinds of touch-based devices. Now you no longer need to fiddle around manually with PathView & friends (as fun as it is, though!), but you can just take the Tumbler control and customize it into your needs!

Qt Quick Compiler 1.1

The Qt Quick Compiler, which was introduced with Qt 5.3.1, allows you to compile your otherwise-dynamically-loaded QML files into native code reducing load-time, enhancing performance on non-JITting platforms and making reverse engineering much harder. For embedded users this release brings robustness in form of multiple bug fixes.

Getting Started

Existing licensees for device creation with Qt can download the updated toolkit via Qt account or using their existing online installer. For new users, contact our sales to purchase a license or request a free 30-day trial via our Download page to get started with creating devices with Qt!

We are looking forward to your feedback!

Qt Creator 3.2.2 released

We are happy to announce the release of Qt Creator 3.2.2. This version of Qt Creator mainly fixes compatibility issues with Xcode 6 on OS X. See the change log for a complete list of changes. Also, we added the option to use Qt Creator under the LGPL v3. For more details about this addition, please check out the blog post “Adding LGPL v3 to Qt”.

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

Animated Blur for Static Images

by author ()

I mentioned before how blurring is a pretty expensive operation so it got me thinking. For dynamic content, we need to do the full thing, and what we have in Qt Graphical Effects is decent, but for static images there are techniques to do it a lot faster.



We can load images from disk, do a bit of processing, and then be able to dynamically animate from sharp to heavily blurred with close to the same rendering performance as blending a normal image, and with minimal memory overhead. Inspired by articles like this and this, I implemented something I think can be quite useful in Qt Quick. This is done by using custom mipmaps with mipmap bias. A QML module implementing this feature can be found here


Below are two screenshots from the test application. The blur ratio is adjusted to keep focus on either the droids in the foreground (topmost) or on the walkers in the background (lowermost). 

Implementation Details 

Mipmapping is normally used to improve performance and reduce aliasing in downscaled textures. In our case, we want to use the mipmap levels to render blurred images instead. Look at the following example:


The original image is on the left. Towards the right are the mipmap levels 1, 2 and 3 for this image, generated using glGenerateMipmaps(). The lower row shows the mipmap levels in their original size and the topmost shows the mipmap levels scaled back up to the size of the original image. Using mipmap bias, an optional argument to the texture sampling function, we can pick a higher mipmap level. When combined with GL_LINEAR_MIPMAP_LINEAR, we can interpolate both in x and y and also between the mipmap levels, seamlessly moving from sharp to coarse. However, the default mipmaps give quite blocky results.

The mipmap levels above are created automatically using glGenerateMipmaps(). It is possible to specify each level manually as well. In the following image, I’ve created mipmap levels by scaling the image down with linear sampling (basically 2x2 box sampling), then applied a 3x3 box blur. The process is repeated for each level based on the previous image. It is not a true gaussian blur, but it comes out quite decent. 



The result is that the mipmap levels are now blurred instead of blocky. Using these mipmap levels and the mipmap bias, we can now select an arbitrary blurryness with a single texture2D() call in the fragment shader. The resulting performance is equivalent to that of blending a normal image, which means this approach is fully doable on mobile GPUs. The mipmap levels adds about 1/3 to the memory consumption, which is quite acceptable. 



Please note that because of the manual downscaling and box blur, the initial texture upload is significantly slower than a plain upload, so it needs be done in controlled places, like a loading screen or during application startup, to avoid hickups in the animation. For a very controlled setup, one could imagine generating all the mipmap levels offline and just upload them in the application. That would save a bit of time, but makes it a bit less flexible. Note also that mipmapping does not mix with a texture atlas, so each image needs to be a separate texture, which means the blurred images do not batch in the scene graph renderer. That means that while we can have several large images being blurred, we cannot have hundreds or thousands of small ones in a scene and expect to sustain a velvet 60 fps. 


So, if you want to incorporate animated blurs of static images into your application or game, have a look at BlurredImage.


Measuring QML Coverage

Last year we started receiving the first requests for QML coverage. “Sure. We’ll look into it.”, we replied. It seemed like a logical extension of our cross-language coverage tool Squish Coco. At least on first sight.

At this year’s Qt Contributors’ Summit the question came up independently in one of the sessions. I had nothing to show back then. But now, there’s finally a prototype accomplishing a proof of concept. To be seen live in action at froglogic’s Qt Developer Days 2014 booth.


With QML finding its way into “real” applications it’s a natural move for quality-aware developers to track its test coverage. A must for safety-critical software. Would it be much different from the current set of supported languages like C, C++, C# or the scripting language Tcl? When looking closer one quickly realizes two fundamental differences:

  • Besides some embedded JavaScript code QML is most about the UI. In fact, there can be zero JavaScript. So no if() statements or for() loops leading to execution flow branching. Just buttons, dials, menus, etc.
  • QML is a declarative language. Leaving the optional JavaScript aside nothing gets executed in the classic sense. By definition there is no control flow.

After some brainstorming and mind-bending sessions we ended up going for a cross-over solution: classic code coverage gets intertwined with what I’ll call “GUI coverage”. The latter measures test coverage by the degree to which control elements are being excercised. For a button this would be a click for example. Same for a menu item. Whether alternate keyboard usage is required as well can be configured.

To demonstrate the output of such an approach we grabbed the sample Unit Converter application Reggie is going to use during Tuesday’s session on Behavior-Driven Development (BDD):


After the GUI gets excercised through a dilligent human tester or a automated testing tool like Squish coverage data will be emitted. Analysis can be done using an interactive tool (see CoverageBrowser screenshot at the top) or an HTML report. The project leader might just care about the overall number. But a developer may want to study details. Was each ‘case’ of a ‘switch’ statement hit? Did each choice of a radio button group get used at least once? Here’s an overview showing percentages for control elements as well as JavaScript code:

Coverage Percent

Analog to coloring pieces of code the usage of graphical elements is visualized: the “Convert” button was clicked (green). The unit selectors remained unused (red). As a result the whole dialog was only partially tested (orange).


Application components implemented in C++ and using QWidgets would be included in above metrics, too. For a live demo visit our booth in Berlin between October 6-8. Others are invited to provide feedback and ask questions via the comment field.

Looking at Throughput in Qt Quick

by author ()

I already talked about the swap test which helps us determine if velvet graphics is indeed possible. The second step I usually take is to benchmark how much graphics we can put on screen before things starts to stutter.

If we focus on pure graphics for now, there are two things worth looking at. Fillrate, which is the systems ability to put pixels on screen; and number of draw calls, which is the number of times we can tell the system to draw something.

Fill rate

When working with software graphics, fill rate is usually the biggest obstacle. The CPU needs to process millions of pixels per frame, potentially both reading and writing. The memory bus will be heavily taxed, and this will eat from the performance budget of the rest of the application. When you have a dedicated GPU however, fill rate is usually not the problem. I’m speaking now in the context of UIs, as both industrial 3D applications and games can easily push the GPU beyond its limits.

A couple of things affect our pixel throughput:


Doing source over alpha blending requires that we take our source pixel and mix it with the destination pixel. The destination pixel is both read and written. So there is a bit of extra work involved. In addition, some GPUs can do even further optimizations like hidden surface removal and early z-test. Such tricks are great for overdraw performance, but they only work when blending is turned off (as in glDisable(GL_BLEND)). On a desktop with a discrete graphics card, chances are this will never be a problem, but for an onboard laptop or mobile/embedded GPU, it just might.


Another aspect that can greatly reduce the throughput of an application is textures. Textures are memory blobs and need to be fetched from graphics memory. The GPU doesn’t always have a large cache, so that means that a lot cycles are spent just fetching texture memory. Working with small textures or small regions of a large texture will in most cases be cheap, while working with full screen images will take its toll.

Shader Complexity

The part of the GPU pipeline that decides the color of a pixel is called a fragment shader. There are other shader stages, like the vertex shader, but the ratio of pixels to vertices is usually so high that the fragment shader is the one that ends up counting. With user interfaces, the majority of fragment shaders are quite simple. The Qt Quick Scene Graph will typically alternate between “colored pixel”, “textured pixel” and “distance field textured pixel”. They translate into a few GPU instructions each. Compared to 3D graphics, we don’t have to deal with lights, normals, bump mapping, shadows and all the other goodness that modern 3D has to offer. There are a couple of exceptions though. For instance anything involving blurring, like Qt Graphical Effects’ GaussianBlur or DropShadow, requires a lot of texture samples to produce a single output pixel. It is very likely that an onboard laptop chip is not capable of running live Gaussian Blur with 32 samples at 60 fps.

So all in all, assuming that the underlying OpenGL stack works properly with vsynced swap and all, raw GPU throughput will usually not be the biggest problem (for user interfaces). Lets look at some numbers.

Overdraw Benchmark 

The benchmark can be found here. It creates a fullscreen Qt Quick window and draws variety of stuff into it. The goal is to see how far we can go with a specific testcase while sustaining a perfect 60 fps. Skipping one frame every 2-3 seconds is in this case considered a failure. Even though we're testing raw graphics performance I use Qt Quick because it is easy to put things together, and for the testcases I've written, the delta between raw OpenGL and what the OpenGL that the scene graph produces is small enough to not impact the results. When they do, I will make a comment about it.


Note: If you try the benchmark, you will see that it does skip frames while increasing and reducing complexity. I'll get back to this in a later post.

I've run the benchmarks on the following hardware: 

  • Desktop Computer: Intel i7-3770K @ 3.50GHz, 24 GB RAM, NVidia GT-210, 1920x1080 screen, Ubuntu 14.04, proprietary driver. Tested with kwin w/o compositor. Also tested with compositor and with unity.
  • MacBook Pro: Early 2011, 4 GB RAM, Intel HD 3000 or AMD Radeon HD 6750M, 1650x1050 screen, OSX 10.9.5
  • iPad Retina Mini: A7, PowerVR G6430, 2048x1536 screen, iOS 7.1
  • Jolla: Snapdragon 400 1.4 GHz dual-core, Adreno 305, 540x960 screen, Sailfish OS u9 (public RC)

What we can see in the graphs confirms what I already talked about. Solid opaque fills are generally extremly cheap, even the mobile GPUs can do 40-50 fullscreen rectangles on top of each other. Same with opaque textured fills, though we should keep in mind here that the scene graph renders opaque content front-to-back with z buffer enabled, so GPUs that implement early-z will end up only having to read the front-most texture. Blending is worse with blended textures being the most costly, though still decent. It is however, something that is worth taking note of. Take, for instance, the following example based on Qt Quick Controls: 


The left image is how it is rendered normally, and the right image is rendered using QSG_VISUALIZE = overdraw in the environment. As can be seen from the visualization, the background is opaque (green) and can be ignored. Then are the three group boxes stacked on top of each other. Each rendered as a separate blended (red) texture. If this or a similar pattern of background stacking was used on a machine that has either a lowend GPU or a GPU that doesn't match its screen size, it would eat a large part of the performance budget. And this is before we start adding the actual application content.

The graphs also seem to indicate that both kwin and unity compositors are quite bad for performance. I could maybe tolerate a 10-20% drop for going through the composition step, but what I'm measuring does not seem right. If anybody knows what's up with that, please give me ping. 

I should also mention that the iPad didn't start skipping frames when I reached 30 opaque textures. It ran out of memory and was killed!


When running similar benchmarks previously, I have seen embedded chips with overdraw performance as low as 1.5. That means the application can fill the screen 1.5 times before the application starts stuttering. In terms of content, that means a background image and a few icons and some text. Not a lot of flexibility. When working with such a system, the application will need to be very careful about what gets drawn if a sustained 60 fps UI is desirable.

What about more complex shaders

I mentioned that complex shaders would be problematic, especially on the less powerful GPUs. To test this, I incorporated the GaussianBlur from QtGraphicalEffects into the benchmark and tested how many samples I could have before it started to stutter. Now, the gaussian blur is implemented as a two pass algorithm. That means that in addition to doing a lot of texture sampling, we’ll also be rendering the equivalent of the screen several times per frame. First into the FBO which will be the source for the first pass. Then blur in one direction into a second FBO. Then blur the second FBO in the other direction onto the screen.


The Jolla managed 55-ish fps with 2 and 3 samples and i7/kwin/composited maxed out at 30 fps, which is why they are marked with 0. Neither managed to sustain a velvet frame rate. The only chip that managed to run with a high sample count, was the discrete graphics chip on the MacBook. This is in line with what is expected, as the complexity of the per-pixel operation grows, so does the requirement for the graphics hardware. What we can read from this is that these kinds of operations needs to be taken into use with some care, applied to smaller areas or otherwise in moderation.

There are alternatives though. For instance, it is possible to do fast blurring even on lowend using a combination of downscaling, simplified blurring and upscaling, such as this. For drop shadows, prefer to use pre-generated ones. Only use live drop shadow if the area is small and there are few instances or you know you’ll be running on a high end chip. Keep in mind that cheating looks equally good. It just runs faster!

Number of Draw Calls 

The other factor I mentioned up top which was worth looking at was the number draw calls. When compared to software graphics, this is where hardware based APIs are much worse. In many ways, the problem to solve is the inverse. With software graphics, at least when looking at QPainter with its software rasterizer, draw calls are cheap and the impact of state changes in the graphics pipeline are small. With OpenGL, and DirectX for that matter, pipeline changes and draw calls can be quite bad. As part of the benchmarks, I’ve created a bunch of unique ShaderEffect items, the scene graph renderer can not batch these, so they will all be scheduled using one glDrawElements() call per item. Lets look at some numbers:

One conclusion to draw from this is that without any form of abstraction layer to handle batching, it is going to be hard to do complex controls, such as a table, using a hardware accelerated API. In fact, this is one of the primary reasons we’ve been pushing the raster engine for the widgets stack in Qt. If we compare this to items that do batch, one of Qt’s autotests will create 100.000 rectangles and can translate them at 60 fps, so the difference is quite significant.


Something else to take note of is that the scene graph is in no way perfect. There are several types of QML level operations which will force items to be rendered one by one. ShaderEffects is one. Item::clip is another. The following is a visualization of Qt Quick Control’s “Gallery” example’s “Itemviews” page using QSG_VISUALIZE = batches in the environment:


At first glance this looks a bit like a christmas tree. If we look beyond that, we see that the majority of the list is drawn in three separate colors. That means that the various background and text elements of the list view have been batched together. Running the same page with QSG_RENDERER_DEBUG = render, we can see from the console output that 109 nodes were compressed to 8 batches. If we added clipping to those list entries, those 109 nodes would be drawn using separate glDrawXxx() calls and eat quite a bit out of our performance budget. 


Another thing that breaks batching is large images, as these do not fit into the scene graph’s built-in texture atlas. If you are curious if the application’s images are atlassed, run the application with QSG_ATLAS_OVERLAY = 1 and look for tinted images.


Closing thoughts


Benchmarks are one thing and the real world is another, but keeping basic rules in mind based on findings in benchmarks can greatly help the overall performance of the resulting application. It is one of the premature optimizations that do pay off. If application performance starts slipping, it can take a lot of work to get it back..

Benefits of the Indie Mobile Licensing

I want to shed some light on and explain the benefits of our recently announced Indie Mobile to make it easier for you to make the right license choice. For certain types of use cases, Indie Mobile provides many advantages in licensing compared to the open-source Community edition of Qt.  Indie Mobile, similarly to the other commercially licensed Qt editions, is also better suited for deployment to third-party application stores. In addition, Indie Mobile as well as the Professional and Enterprise editions, allows licensees to retain more flexibility with regard to their own product licensing.

With the introduction of the Indie Mobile, I thought I would take the opportunity to provide you with some guidance on how to make the right license choice for you when developing with Qt.  The purpose of this post is to provide clarity on use cases on when to use the commercial editions of Qt, in particular Indie Mobile, and when to use the open source Community edition.  Please note that the purpose of this post is not to give legal advice on compliance in your specific circumstances. If you have concerns about licensing, you should consult an attorney experienced with open source licensing issues to make sure you are compliant.

As a general statement, I want to emphasize the importance of our open-source  Community edition of Qt to the development of Qt as a whole. We make Qt available under open-source license to allow the community to develop open and easily accessible products with Qt, and at the same time contribute back to its development making it an even better technology. We greatly value this co-operation and want to endorse it. However, we recognize that the open-source model is not necessarily the right approach for all licensees. Typically our commercial license terms are better suited for creation of proprietary applications – and for that reason we cater to all needs with the various licenses pursuant to which we offer Qt.

In order for you to make an informed decision when choosing which edition you should develop with, I want to provide you with our point of view on two licensing models and the impact they have on your mobile application development. I will start with the Community edition and open source development, and follow-up with some specific observations about how our commercial Indie Mobile license differs from the open-source LGPL license.

Community Edition – Respecting the Four Freedoms

The Lesser General Public License (“LGPL”) (initially version 2.1, and with Qt 5.4 also version 3) has been chosen as the primary open-source license for Qt because it provides users with the following four freedoms:

  • The freedom to run the program as you wish, for any purpose (freedom 0).
  • The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
  • The freedom to redistribute copies so you can help your neighbor (freedom 2).
  • The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

These four freedoms are essential for the success of open-source co-operation. Therefore, it is vital that all users of Qt under the LGPL respect these freedoms by fully complying with all the requirements set by the LGPL.

General LGPL compliance

The LGPL, like most open source licenses, imposes several obligations on distributors of LGPL libraries. As a general rule, the LGPL works very much like the GPL in that the derivative works of LGPL libraries need to be licensed under the LGPL as well. However, if the LGPL’s so-called library exception applies, the user can license the combined work under a license of their choosing. Even if the library exception applies, the LGPL imposes requirements that need to be complied with.

These include, but are not limited to:

  • Inclusion of proper copyright and license notices.
  • Disclosure of the source code of the library, modifications of the library, and in some cases, the source code of the application itself.
  • Ensuring that the proprietary license of the actual application allows reverse-engineering as required by the LGPL.
  • Re-linking and running the application with a modified version of the library.

The last item in is one of the main requirements of LGPL, which we believe to be frequently overlooked. Is a requirement of LGPL to allow the user to be able to re-link and run the application with a modified version of the open-source library (right to run the application is clearly stated in LGPL version 3, and we believe it should be allowed also when using LGPL version 2.1).

These rights granted to users is at the core of the Qt’s Community edition, and we believe that all licensees of the Community edition should ensure that users of their applications can exercise these rights.

LGPL compliance when distributing via third party application stores

The wide degree of user freedom granted by the Community edition of Qt can create difficulties when software is distributed via third party application stores. In the particular case of mobile devices, the technical restrictions on the underlying technical platform and the terms of the stores themselves can make compliance with these requirements difficult – and in some cases impossible. Practical compliance difficulties arise from the fact that certain platforms provide only limited support for shared libraries (the typical case where the LGPL’s library exception applies), and the platform and the terms of use can restrict the possibility for the user to run modified versions of the libraries on the device unless they have been digitally signed by the vendor and/or the distributor. If the application cannot be designed in a way that complies with the library exception in the LGPL, a likely scenario is that the whole application must be distributed in source code under the LGPL. It is also possible that distribution via certain stores is not allowed at all.

As can be seen from the points identified above, compliance with the LGPL is not a matter of packaging the application with the library and running with it. There are many issues to take into account, and compliance must be considered already at the design stages. If this is not done, the distribution of the application is highly likely to run into difficulties.

Commercial Editions  – Flexible Licensing

In some cases, compliance with the four freedoms is not a possibility due to practical reasons. There are various scenarios where this might be the case:

  • You might want to utilize some component with a license model that is not compliant with the requirements set by the LGPL.
  • In some cases the distribution channel or the technical implementation of the underlying software platform can restrict your ability to comply with the LGPL.
  • If you want to distribute your application through third party application stores, the terms and technical restrictions of the application store and the underlying device ecosystem can limit the possibility to fully exercise these freedoms.
  • You might want to have terms in the End User License Agreement of your application that are not compliant with the requirements set by the LGPL, for example restricting reverse engineering or patent license rights.
  • You may not want to provide all the source code of Qt with your application to every user of the application or deliver the source code upon request based on your written offer to receive the source code. It is explicitly on the responsibility of the application developer to distribute all the used source code (of Qt) to every user downloading the application, even if there are no modifications to it.

In such cases a commercial Qt license, such as Indie Mobile, is a more suitable license alternative to the LGPL. The Qt commercial licenses simplify compliance by eliminating the LGPL license requirements that limit your ability to license your application as you wish, and by removing the legal obstacles that can in certain cases prevent you from distributing your Qt-based applications via third party application stores. In any proprietary application, it is our strong recommendation to use commercial editions. In this way you can ensure your compliance of license terms and ensure your IPRs are better secured.

Which Qt Edition Should You choose?

We believe that the Community edition is best suited for those users who want to develop open source applications. If you intend to develop either closed source applications, or distribute your applications through a third party application store, we would recommend our commercial license editions. Use of the LGPL licensed Qt is in some cases possible in closed source applications and in applications distributed via third party application stores, but in such cases you should take the steps necessary to fully comply with the LGPL’s rules on combined works and be ready to grant the users the Four Freedoms they are entitled to. You should also pay particular attention to any restrictions a third party application store might place on such freedoms in order to ensure that you can legally distribute the application via such a channel.

When you are beginning your Qt development and if you have any doubt whether or not the requirements of the LGPL can be met in full, a commercial licensing option is often the best choice. Indie Mobile has been created as an affordable alternative for individuals and small businesses (below yearly revenue of 100.000€) to be able to deploy their applications via public applications stores. By using the Indie Mobile, the particular challenges created by third party application stores are removed, meaning that you as a developer can distribute your application via whatever third party application store you wish.

I hope this post has made the licensing of Qt a bit clearer and given you some insight on the benefits of Indie Mobile. You can also check our licensing pages for more information. I welcome your feedback and look forward to hearing from you.

Merged Proxy Model is now LGPL

I was really ashamed today as I've found that Blogger was sending information about comments on the blog to my kindle e-mail... But also I've found that some people are interested in Merged Proxy Model described on this blog (but only as LGPL).

I've asked all developers that have their input in this nice solution and there it is:

available as LGPL2.1+ Enjoy!

Fixes from blog comments not yet included.

Grantlee 5.0.0 (codename Umstraßen) now available

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

I invented the word ‘umstraßen’ about 5 years ago while walking to Mauerpark with a friend. We needed to cross the road, so I said ‘wollen wir umstraßen?’, because, well ‘umsteigen’ can be a word. Of course it means ‘die Straßenseite wechseln’ in common German, but one word is better than three, right? This one is generally popular with German native speakers, so let’s see if we can get it into the Duden :).

This is a source and binary compatibility break since the 0.x.y series of Grantlee releases. The major version number has been bumped to 5 in order to match the Qt major version requirement, and to reflect the maturity of the Grantlee libraries. The compatibility breaks are all minor, with the biggest impact being in the buildsystem, which now follows patterns of modern cmake.

The biggest change to the C++ code was removal of a lot of code which became obsolete in Qt 5 because of the QSequentialIterable as part of the type-erased iteration features.

Wayland and Qt 5.4

Since nobody else has done the honors yet, I'm happy to announce that - as decided at the Qt Contributors Summit this year - support for running applications under a Wayland compositor will be seeing its initial release with Qt 5.4. That is, the QtWayland repository is finally going to stop sitting in the corner, sulking. :)

There's a few "buts", though.

Firstly, it should be noted that support for QWidget-Based applications (and other desktop-based usecases) may be far from ideal, and quality may not be great. This is a consequence of most development on QtWayland having been driven from mobile/embedded viewpoints to date, and is not, in general, an inherent limitation on the windowing system. It's also something of a reflection on Wayland itself, which is only now starting to mature for desktop use (through xdg-shell etc etc.)

tl;dr: Think of this as a technical preview, keep your expectations realistic, and if you want to use it, expect to roll up your sleeves a bit and get dirty from time to time.

Secondly, the QtCompositor API in the QtWayland module (allowing you to write your own Wayland compositor) will not be seeing a release at this time. The API is not frozen, and has not seen the usual polish/quality that you might expect from Qt APIs. As this API is only of use to a limited number of people (those looking to implement an embedded/mobile device, typically, or write their own DE) this should not impact too many people.

tl;dr: If you want to write a compositor, you get to keep both pieces if it breaks. If you want to use applications under an existing Wayland compositor, you're fine.

Future work to QtWayland is largely an open story, but some obvious candidates come to mind:

  • Continued work on xdg-shell support
  • Plugin based window decorations (to enable environment-specific look and feel) this has now landed in the 5.4 branch :)
  • Integration with the rest of Qt's autotests (I spent a while getting tests fixed or at least runnable under window-compositor, but it would be nice to automate this)
  • "Official" subsurface protocol support
If there's something you would like to see happen, here or not, you're more than welcome to pitch in. If you'd like to talk to the other people hacking on QtWayland, please pop by on #qt-lighthouse on freenode, and talk to the folks there :-)

I'd also like to take a moment to thank everyone for their contributions to QtWayland. In particular, I'd like to say thanks to the following, in no particular order (and I'm extremely sorry if I've missed someone, please let me know and I'll happily add you to the list):
  • Kristian Høgsberg & Jesse Barnes, for their initial work on the port, sponsored by Intel,
  • Jørgen Lind, Samuel Rødal, Andy Nichols, Laszlo Agocs, and Paul Olav Tvete for continuing work on it excellently and admirably,
  • Nokia for sponsoring a good deal of the development up until their abrupt departure from the Qt world,
  • Digia for continuing to help out after Nokia left,
  • Andrew Knight, for ably shepherding problems encountered by Jolla for quite a long time,
  • Jolla for sponsoring a large chunk of work on QtWayland (past and present),
  • Gunnar Sletta for rewriting integration with rendering (especially QtQuick), removing a large number of bugs & improving performance,
  • Giulio Camuffo for numerous fixes, improvements and interaction with the wider Wayland community.
As a conclusion, I'd like to note that I'm really happy to see this finally happen - I've wanted it for a very long time now - and for Wayland to keep moving on for bigger and better things. Hopefully, this release will achieve its intended result (that more eyes/hands get exposed to the code, and start to use it, and help out with it).

Qt Fix and Polish Week

Last week we took a fresh look at bugs, examples and tests. Now the “Qt Fix and Polish Week” is over and it’s time to summarize. Most of the people working on Qt inside Digia participated, but it was especially great to have many people join us on #qt-bugs and contribute. On Monday morning we had a quick sync round to split into teams. Each team had a defined goal and much work got done.


In the bug triaging and fixing track we got our hands dirty to fix issues in all areas. For some of us inside Digia this also meant getting to know parts of Qt that we weren’t as familiar with and a great opportunity to exchange knowledge while working in a different setup. This is something we certainly will repeat – do an effort to work across teams to be even more efficient in bug triaging and fixing and getting an overview of the situation for Qt 5.4. We closed many bugs, and hopefully some of you out there saw your own reported bugs get fixed.

Qt comes with a lot of examples. We continued the polishing effort of them that we already had started on some time back, and focused on a few of them to have them shine on all platforms and make sure they give a good first impression, for example when running Qt Creator for the first time. There was a huge list of suggestions that got done, from improving the color scheme to making things work on Android and iOS devices. The task is overall so big that it is still ongoing, but last week was a great start getting people involved in the work.

Auto tests and QA
The original focus of the test fixing team was the reliability of the continuous integration (CI) system. While the system helps us deliver a well tested and stable Qt by make sure the huge amount of tests run without failure for every change that goes into Qt, a few of the tests sometimes result in that the CI doesn’t run as smoothly as we’d like it to. A lot of discussions took place on how we can improve our tests and the CI in general. We had many small initiatives to fix different parts, and to stabilize, fix and re-enable tests. The results are now becoming visible as the fixes make it through the CI.

Feedback about how to arrange differently next time? Please let us know!

Hopefully we’ll be able to coordinate and announce better and earlier the next time we arrange such an event. We will likely focus only on bug fixing, and we will coordinate using IRC again.

Already on Friday afternoon we had a wrap-up session in Oulu, Berlin and Oslo. We concluded that we had had good progress, and that this is something we would like to repeat, maybe for each release. It was great to see people from the community outside Digia join. Especially the “yeahhh submitted my first patch to Qt” on IRC was nice to see, and hopefully we also helped more people get started contributing to Qt and scratching their own itch!

Thanks a lot to all participants!

Cake with Qt logo and bug on the icing

Qt on QNX

When BlackBerry introduced its new Qt-based BlackBerry 10 platform for smart phones and tablets, it generated a lot of interest in Qt on mobile. BlackBerry 10 is based on the QNX 1 operating system, a subsidiary of BlackBerry.

What is perhaps not as well known, is that Qt is well supported on QNX as an embedded operating system in its own right.

The Swap Test

by author ()

This is a test that I usually perform as a first step when encountering a performance issue on a new machine. It establishes whether or not velvet animations are possible at all. It is super simple and works pretty much everywhere. My equivalent of glxgears, you might say. The idea is to show a fullscreen rectangle and alternate the color between red and blue (or any combo of your choice) as fast as swapBuffers() allows. If the visual output is a shimmering, slightly uncomfortable, almost solid pink, then swapping works as it should. 


Here is the test, implemented using Qt, EGL, QML (via frameSwapped) and QML (via animation system).

People having issues with flashing light should avoid this particular test.


Because of a phenomenon we call persistence of vision, the red and blue color will stay in our retina for a fraction of a second after we switch to the alternate color. As long as the color is changed at fast and regular intervals we will observe a solid, shimmering, pink. If the color is changing at uneven intervals, it becomes really obvious. In theory this should be a matter of setting swap interval to 1, but it doesn’t always work. Perhaps more so on Linux.


If there is one or more horizontal lines across the screen, this is an indication of tearing. If the screen flashes with frames in which you can clearly see the red and blue colors, it is because frames are being dropped or because frames are rendered too fast. Check the driver and/or the compositor for vsync settings. Disabling the compositor is another thing that might help. There are a number of things that can be tweaked. Generally, I've found proprietary NVidia and AMD drivers produce solid results out of the box.


If the “QML (via animation system)” test fails and the others pass, you might be looking at a case of timer driver animations. On Linux, we’re using the basic render loop for mesa drivers. Run it again with QSG_INFO=1 in the environment and see if it prints out “basic render loop”. This was chosen some time ago as a sensible fallback in case we didn’t know what we were dealing with. Our primary worry was spinning at 100% when the GL stack was not throttling us, so safer to tick by timers to draw only every 16 ms. As you probably know, ticking animations based on timers does not lead to smooth results, so an alternative is to specify QSG_RENDER_LOOP=windows (yeah, windows… just accept it) in the environment. This render loop will tick animations in sync with buffer swapping and will look much smoother.


Grantlee 0.5.0 (codename Auf 2 Hochzeiten tanzen) now available

The Grantlee community is pleased to announce the release of Grantlee version 0.5 (Mirror). Source and binary compatibility are maintained as with all previous releases. Grantlee is an implementation of the Django template system in Qt.

This release builds with both Qt 5 and Qt 4. The Qt 5 build is only for transitional purposes so that a downstream can get their own code built and working with Qt 5 without being first blocked by Grantlee backward incompatible changes. The Qt 5 based version of Grantlee 0.5.0 should not be relied upon as a stable interface. It is only there to assist porting. There won’t be any more Qt 4 based releases, except to fix build issues if needed.

The next release of Grantlee will happen next week and will be exclusively Qt 5 based. It will have a small number of backward incompatible changes, such as adding missing const and dropping some deprecated stuff.

The minimum CMake required has also been increased to version 2.8.11. This release contains most of the API for usage requirements and so allows cleaning up a lot of older CMake code.

Also in this release is a small number of new bug fixes and memory leak plugs etc.

Testing Qt and QML applications @ Qt Developer Days

We are all excited that the prime Qt event of the year, the Qt Developer Days, is approaching and only 3 weeks away!

We at froglogic would like to thank KDAB, ICS and Digia for organizing this again. It will be great to meet many known faces and new Qt enthusiasts.

We will present the latest and greatest version of our GUI Test Automation tool ‘Squish’ and Code Coverage Analysis Tool ‘Squish Coco’.

At our booth you will be able to see Squish testing Qt and QML/QtQuick applications on various desktop platforms, embedded platforms and mobile platforms.

For those who want to get an in-depth introduction to Squish for automated Qt and QML testing, one of our senior training instructors will conduct the Introduction to Testing Qt applications with Squish training class on Monday, October 6th.

On Tuesday, October 7th, we will showcase Squish right after lunch.

On Wednesday, October 8th, I will give a talk about Behavior-Driven Development and Testing of Qt C++ and QML Applications where I will present how the BDD methodology can be applied to Qt/QML and specifically GUI tests.

We are looking forward to meet you all at the Qt Developer Days :-)

The Qt Company Introduces a Unified Website and 20€/$25 Monthly Indie Mobile Package

We have a lot of news to share with you today.

In June 2014, we announced via a stock exchange release that a new company entity for Qt under the parent company Digia Plc. would be formed. Today, I am very happy to be able to announce the new name as “The Qt Company”. Sweet and simple.

With The Qt Company as a separate entity, we will be able to put more focus on our Qt business operations to better position our beloved Qt technology in the software industry. We will now begin to use “The Qt Company” as our umbrella to market and promote Qt. The Qt Company has been registered in all countries where we do business and have offices.

One Unified Site | www.qt.io

In addition, we are today also launching the first phase of our unified Qt web site that I talked about in my blog post a month ago. We are launching this new website under the new domain qt.io. This new website will serve as the main digital communication channel for everything relating to the Qt product. The plan is to combine the qt.digia.com and qt-project.org web pages and online communities into one happy Qt world. In this first phase, we have started to redirect traffic from qt.digia.com to www.qt.io. You will also notice that under www.qt.io/download we have unified our package download options where our open source and commercial versions can be accessed from one location. In the next phase, we are planning to begin to move over content from qt-project.org to link directly from the new site under the “Developer” section. More information on that transition will come soon.

Another thing to take note of is our fresh new design and layout, plus a slightly updated Qt logo, which I hope you will like as much as we all do. We put a significant amount of effort to make sure that we highlight all the great things about our technology. Our goal with the new web site was to convey a simple, yet powerful message to our varying target audiences as to why everyone should develop with Qt. I hope we succeeded.

A great new offering for Indie Mobile Developers

Many of you have been asking for it, and we have listened. On top of the new web site and company name, today, we are also releasing a brand new Indie Mobile package targeting Android, iOS and WinRT development. You get the Qt libraries, Qt Creator, a commercial license and full development and deployment rights to the Android stores, App Store and Windows Marketplace (Note: the package doesn’t include support, commercial add-on features or Qt Cloud Services). The new package is available for the price of 20€/$25 per month on www.qt.io. I hope this package will fill the needs of many of the independent developers in the community.

Qt 5.3.2 and Qt Creator 3.2.1

Finally, I would also like to mention that earlier today we did a Qt 5.3.2 and Qt Creator 3.2.1 release, rounding up the news we are having for today. Make sure to read those blog posts as well.

We hope that you have enjoyed our day of Qt announcements. Have a look at our new www.qt.io website and please let us know what you think. If you’re using Qt 5.3, make sure you get the update to 5.3.2. If you are an indie mobile app developer, you just have to grab our new Indie Mobile package. Download it now. We look forward to your comments.

Qt 5.3.2 Released with Qt Creator 3.2.1

Today we have released Qt 5.3.2, the second patch update to Qt 5.3. In addition to improvements and fixes to Qt functionality it also packs Qt Creator 3.2.1 along with nice additions and patches to Qt Quick Compiler, Qt Quick Enterprise Controls and Qt Purchasing.

Also, with Qt 5.3.2 we are extremely proud of rolling out the new licensing tiers, now including the much-desired Indie Mobile tier. See the blog post about all the new announcements, and visit the new Qt download page for your copy of Qt 5.3.2!

With Qt 5.3.2 we are providing nice set of bug fixes and enhancements thanks to all the feedback and reports we’ve received! Qt 5.3.2 maintains backward and forward compatibility, both source and binary, with Qt 5.3.0 and the latest, 5.3.1, which was released this June. The list of changes can be found from the change files for each module.

The packages of Qt 5.3.2 also include new Qt Creator patch release, Qt Creator 3.2.1. See the blog post about Qt Creator 3.2.1 for details.

We are also releasing nice updates to a bunch of add-on modules for commercial Qt licensees, all installable through your Qt online installer. The new and exciting Qt Quick Compiler gets its first update and we are adding the long-awaited Tumbler control to Qt Quick Enterprise Controls! Here’s the overview of updates to Add-On modules:

Qt Quick Compiler 1.1

The Qt Quick Compiler, which was introduced with Qt 5.3.1, allows you to compile your otherwise-dynamically-loaded QML files into native code reducing load-time, preventing reverse engineering and enhancing performance on non-JITting platforms. In this release we have fixed important bugs and added initial support for projects built with CMake.

Qt Quick Enterprise Controls 1.2

Finally, the Tumbler is here! The Tumbler control is well-known in mobile user interfaces and much used in all kinds of touch-based devices. Now you no longer need to fiddle around manually with PathView & friends (as fun as it is, though!), but you can just take the Tumbler control and customize it into your needs!

The Tumbler QML element

Behold! The Tumbler is here!

With the 1.2 release, we are also improving the existing set of industrial UI controls. See the documentation for full list of pre-made controls.

Qt Purchasing 1.0.1

The Purchasing module that gives you a convenient cross-platform in-app purchasing API is also getting a patch to improve functionality on iOS. For details of usage, see the documentation.

You Got Me at Qt 5.3.2, Where Can I Get All This?

We’ve now greatly simplified the download process with the new unified Qt.io pages. Visit the new downloads page to pick up the right version for you. You can also use the package maintainer of your existing Qt online installer to roll the updates, or existing licensees can pick up installers directly from Qt Account.


Qt Creator 3.2.1 released

We are happy to announce Qt Creator 3.2.1. This release contains a range of bugfixes, including fixes for:

  • a freeze when using the current project or the all projects locator filters via keyboard shortcut
  • a deployment error in the OS X packages which led to the Clang code model plugin not loading
  • a crash when opening the context menu on C++ macro parameters

For a full list of fixes, please see our change log.

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

Kiosks and Learnable Interfaces

When a person encounters a kiosk or computer device in a public space, such as a sales or museum kiosk, they can only benefit from it if they can figure out how to interact with it rather quickly. So one of the requirements of public interactive devices is that they be very easy to use, or easy to learn to use. But the learnability must be part of the user experience design. Depending on the content, a design may use very common interactive navigation patterns such as “next” and “previous” buttons that leave no questions about how to interact with them.

What's coming to Green Island: part 1

I want to share with you some of the progress I recently made.
This is not all, more will come in another post.

Multi output support: part 1

Green Island now supports multiple outputs.

QtCompositor only support one output so in order to do this I did a little abstraction to enumarate outputs and played with QML to show them in the compositor window.

How does it work?

It's pretty simple: it has a ScreenModel that provides data such as name, primary boolean flag and geometry. The main QML file has a repeater using this model to create an OutputView for each output.

Every OutputView has layers to stack different kind of windows (panels, lock screen, workspaces), one of the layers is HotCorners which contains 8 hot corners.

During test and development one often need to fake outputs to test several different configurations without having real monitors, but this requires a dedicated backend and a configuration format.

So ScreenModel has its own backend code, one of the backends is based on QScreen and the other is for fake outputs.

Studying the problem and doing some prototype made me realize that QScreen has a very limited API (for example it doesn't detect when the primary output changes) and that this matter was already implemented with libkscreen.

It happens to be a framework that doesn't pull in undesired dependencies, so now Green Island is using it and I have to say it saved me a lot of work.

In the video below you can see a Green Island window with two 1024x768 outputs side by side, at some point the first one (which is also primary) is removed and all the windows are migrated to the other output that is now the new primary output.

Multi output support: part 2

A single big fat window for all the outputs is not such a great idea, it was good enough to continue the development keeping multiple outputs in mind but it's not the solution in the long run.

Such a solution may hit hardware limits pretty, plus outputs can have a different refresh rate so they really should not be done this way.

QtCompositor handles only one window so I patched it to be aware of multiple outputs with one window for each of them.
The patch targets the dev branch and at the time of this writing is in the review queue.

All the QML code was reused except for the Repeater and the logic to move windows when an output goes away was moved to C++.
This means that almost none of the code previously wrote was removed.

The hard part came when I needed to figure out how to show the same surface on multiple output windows.

Considering that QQuickItems cannot be shared between multiple windows I had to create a view for each output.

When a shell surface is created for a surface, the compositor creates a view that inherits from QQuickItem, the output is assigned based on the mouse pointer coordinates. No other view is created at this time because the position is calculated to be within output bounds considering the surface size.

More views are created on demand when the surface is mapped.

As windows are moved all views are moved accordingly, global coordinates are mapped to the output coordinates so that windows are shown only where they are meant to be.

Unresponsive applications

Wayland offers a ping/pong API that compositors use to know whether a surface is responsive or not, even with CSD (in the past there was some concern about this).

When a window is clicked, Green Island ping the surface and if it doesn't reply with a pong within 200ms it marks it as unresponsive and apply a colorize effect, draw some explanatory text, and intercepts mouse input. It also adds a couple of push buttons, one to wait for the application to become available again and the other to brutally murder the application.