Qt Quick Controls for Embedded

Qt Quick Controls are a set of styled UI controls to conveniently build user interfaces in QML. The first release of Qt Quick Controls was included in Qt 5.1 and targeted desktop platforms. Subsequent releases have also vastly improved the support for mobile platforms.

Qt Quick Controls are not only offered for convenience, but also act as an example to vendors wanting to create their own UI control sets. Unlike specialized control sets for a defined target platform, Qt Quick Controls have a broad scope from desktop to mobile and embedded. This has led to a flexible, but somewhat complex design.

When targeting embedded hardware with limited resources, we would like to offer better performance than what the current set of Qt Quick Controls provide. Over the past months, we have spent a great deal of time researching, profiling, and discussing alternative approaches. We would like our customers to enjoy the convenience of Qt Quick Controls everywhere without a significant performance impact.

We now have a promising prototype up and running, so we thought it would be a good time to share the status. We have posted a little sneak preview showing the new controls in action. Please notice that the visual appearance is not final.

The following sections highlight some of the ideas that together helped to achieve a remarkable performance boost.

QML vs. C++

In many cases, the internal state of a control can be more efficiently processed in C++. For example, handling input events in C++ makes a difference for controls that would otherwise need to create internal MouseAreas and attached Keys objects. By doing all the heavy-lifting in C++, the visual QML layer could be implemented using simple and efficient declarative bindings.

The following charts present creation times of various Qt Quick Controls compared to what we have now in the works.



As you can see, on a device like RPi, one still cannot create too many controls per frame when aiming for 60 FPS scrolling. We are clearly headed the right direction, though. :)


The new controls are spiced up with a customizable, light-weight and platform independent Qt style that performs well on devices with limited resources. The concept of styling is changing in a way that styles no longer provide components that are dynamically instantiated by controls, but controls themselves consist of delegates that can be replaced without dynamic instantiation. Style objects on the other hand have become simple sets of styling attributes. In order to brand an application, changing the color scheme is a matter of setting a few properties that are automatically inherited by the hierarchy of children.

Keep things simple

When it comes to more complex compound controls, it is sometimes better to provide the sub-controls as separate building blocks. As an example, we consider replacing the complex ScrollView control by simple ScrollBar/Indicator controls that can be attached to any Flickable:

ScrollView {
    horizontalScrollBarPolicy: Qt.ScrollBarAlwaysOff
    Flickable {

// vs.

Flickable {
    ScrollBar.vertical: ScrollBar { }

Maybe not entirely fair to compare these two approaches, but here’s the gain of the oversimplification in numbers:



Wrap up

We have been exploring a bit what it would take to bring Qt Quick Controls to the segment of devices with limited resources. Some ideas, leading to significant performance improvements, are presented above. The performance comparisons focus on creation time, which reflects directly to application startup time, loading time of application views, and scrolling speed of item views that create and destroy delegate instances while scrolling. Simplifying things and doing all the heavy-lifting in C++ reduces memory consumption as well. Currently a Button using the “Base” style consists of 17 Items (of which 4 are Loaders) and a total of 64 QObjects. The amount of Items of a Button is now down to 3, and the total amount of QObjects is 7 at the moment.

Please bear in mind that the new light-weight controls are still in early development. The numbers, visual appearance, and the whole concept are still subject to change.

The post Qt Quick Controls for Embedded appeared first on Qt Blog.

C++11/C++14 Training Sold Out! New one in May!

KDAB’s popular 3 day Training course: What’s new in C++11/C++14 training has SOLD OUT in April but don’t despair, you can still get up to speed with the new language for better productivity and performance in your project.

KDAB’s Thomas McGuire is putting on bonus session just for you: 11th – 13th May, at our training facility in Berlin, Germany.

Register now! Training for professional C++ developers

This KDAB training has features such as improved lambas with lambda init capture and generic lambdas, relaxed constexpr, variable templates, improved return type deduction, binary literals, digit separators, a deprecated attribute, decltype(auto) and some library additions in places like iterators, algorithms, literals, type traits and more.

The course also offers optional advanced C++11/14 features like variadic templates and perfect forwarding. All our training material is clearly marked for C++14 improvements you can choose to ignore if you work with C++11.

Read more…

The post C++11/C++14 Training Sold Out! New one in May! appeared first on KDAB.

qt-project.org to redirect to qt.io/developers

We are happy to announce that our “One Qt” unification project will soon reach its major milestone. On April 1, we will redirect the remaining pages to qt.io. qt-project.org will redirect to qt.io/developers.

If you have been following our progress, you know that the forums have already been redirected since their migration a couple of weeks ago, as well as the documentation. Both services are working well in their new homes.

The last major user service that the redirects will impact is the Qt Wiki. The new wiki has now been open for almost a month, and it has been adopted well by the community. It has seen clearly more activity than the old wiki, as the platform is more familiar to everyone, making it more approachable and familiar to use.

Some of the services in qt.io will require Qt Account credentials for logging in. Both the Qt Wiki and Qt Forum use Qt Account as their login service and we are planning to introduce more services and benefits to Qt Account in the near future.

If you are wondering what happens to the username you had on qt-project.org, it has been reserved for your e-mail address in Qt Account. When you create a Qt Account, please do it with the same e-mail address as you used on qt-project.org, that way you can connect to your old forum information.

It is important to note that while the services for users of Qt are being unified under the qt.io domain, the resources for developing Qt itself are staying in the qt-project.org domain. The codereview with it’s repositories will still be at codereview.qt-project.org and the mailing lists are staying at lists.qt-project.org.

For the next phase of improving our developer pages, we would like to hear from you what the homepage of qt.io/developers should look like. We will be updating that page to include information, links and whatever you feel is needed. Please share your thoughts via this thread in the Qt Forum.

As this has been an incremental project together with the community, we have received lots of feedback that have helped this project go as smooth as possible. Naturally, there will be some things that won’t be exactly as they were on qt-project.org and DevNet, however, as we move into maintenance phase, we will also add improvements and new programs that will benefit you.

We thank you for your support in working with us to make this a smooth transition and believing in the “One Qt” initiative. We also thank  the qt-project.org and DevNet site, which established the first digital global home for our ecosystem. We don’t want to say “good bye” to qt-project.org nor to DevNet, but “See ya” as we welcome it into qt.io and our unified ecosystem.

As always, we appreciate any feedback you have.

The post qt-project.org to redirect to qt.io/developers appeared first on Qt Blog.

The current state of Windows Embedded Compact (WEC) platform support in Qt

by Björn Breitmeyer

It has been very quiet around WEC platform support in Qt, and you would have been forgiven for thinking that nothing was happening. But behind the scenes, we have been tackling some pretty hard issues. We just did not blog about the ongoing work….until now.

Be assured that the platform is still maintained and there is work happening. Here is a short overview of the work my co-worker at KDAB, Andreas Holzammer and myself have done on the WEC support.

Qt Multimedia Qt Multimedia is still listed as a not supported module for WEC. This has changed slightly as we reintroduced the ability to playback audio files based on the DirectShow backend: https://codereview.qt-project.org/#/c/93093/.

Read more…

The post The current state of Windows Embedded Compact (WEC) platform support in Qt appeared first on KDAB.

Qt Developer Days Videos and passing the torch

For the past three years, KDAB has had the honor and pleasure to bring you the European Qt Developer Days Conference in Berlin. Now it’s time to pass the torch and, we’d like to offer you a farewell gift:

Watch the videos!
Videos from the 2014 Qt Developer Days Europe are now online along with videos and slides from 2013 and 2013 – all at a single location. Enjoy! And thanks for the ride.

Last month The Qt Company announced the Qt World Summit, to be held again in Berlin at the bcc Berlin Congress Centre. RIP Qt Developer Days, Welcome to the Qt World Summit!

Read the back story from KDAB’s Chief Executive, Kalle Dalheimer here…

The post Qt Developer Days Videos and passing the torch appeared first on KDAB.

Saving code

As you probably know by now, Gitorious is shutting down. A lot of history sits on that site, and much of the code is no longer maintained. Browsing around, I ran into the maemo-tools that has not been touched since 2013. There are still some useful stuff there, so I decided to save it. All tool repositories has been cloned to the maemo-tools-old organization on github.

As I’m only a happy user, I would love to invite the original maintainers, or other interested developers to come work on it, so if you want an invite to the organization so that you can maintain the code, just drop me a mail at e8johan, gmail, com.

Effective Surge Strategy

At some point in any extended-length development project -- whether it’s a multi-year project or a multi-month project -- you’re going to need what I’m calling a Surge. What’s going to prompt a Surge?

Here are some examples:

The current state of Windows Embedded Compact(WEC) platform support in Qt

It has been very quiet around WEC platform support in Qt, and you would have been forgiven for thinking that nothing was happening. But behind the scenes, we have been tackling some pretty hard issues. We just did not blog about the ongoing work……until now.

Be assured that the platform is still maintained and there is work happening. Here is a short overview of the work my co-worker at KDAB, Andreas Holzammer and myself have done on the WEC support.

Qt Multimedia

Qt Multimedia is still listed as a not supported module for WEC. This has changed slightly as we reintroduced the ability to playback audio files based on the DirectShow backend: https://codereview.qt-project.org/#/c/93093/.

We also tried to restore the Video support, but faced unknown error messages from DirectShow. The idea of reviving the support is not gone, but delayed until we find a solution.

Deploying Qt Applications

Deployment of Qt applications can be quite a hassle. You have to know which plugins and modules your application uses and make sure all the required files that are not stored in resource files are deployed. This is especially bad if you have Qml files and plugins. The Qt Company introduced a very useful tool to ease the deployment on windows, called windeployqt. In January we finally got the support for WEC in the windeployqt tool upstream: https://codereview.qt-project.org/#/c/92707/.

This helps to simplify the deployment of Qt applications onto a target. You still have to manually copy the files and the libc++ runtime to the device, but all the Qt dependencies are correctly packaged to a folder of your choice by running a simple command.

Multitouch Support

Last but not least we have integrated a new feature into Qt 5.4. We introduced multitouch support for WEC based systems, this means we have two-finger multitouch working in Qt on WEC platforms. This happened in January when we implemented support for GID_DIRECTMANIPULATION: https://codereview.qt-project.org/#/c/104040/.

Only two touch points are supported due to the very simple WEC api for this, which only offers us two. The new feature allows WEC7 Qt application to use all the Desktop gesture recognizers.

While we were implementing the multitouch feature we discovered that the delivery of touchpoints and gestures was not working properly. The events weren’t reaching the correct widgets most of the time. The reason was a porting bug from Qt4 to Qt5, where the new call for the Desktop api was available on WEC7 but didn’t work properly. This led to the inability to find the correct child window for given coordinates. The bug we fixed was QTBUG-44022.

Ongoing work

As WEC7 is already a very old platform and Microsoft has already released the successor, we were looking for an integration of WEC2013 as a supported Qt5 platform. Recently we succeeded to compile and deploy a Qt5 application to WEC2013. Our hardware platform still gives us trouble with Qml Shader elements, but simple QtQuick2 applications are working already. The port will go into Qt very soon. First we need to verify what features are working and take a look where we can now actually use the more feature-rich desktop code paths. This should ease maintenance and will allow us to fully leverage the capabilities of a new platform.

We will blog about the release of Qt5 WEC2013 platforms support in the near future when we have pushed the support upstream.

The post The current state of Windows Embedded Compact(WEC) platform support in Qt appeared first on KDAB.

Beta Distribution For Mobile Qt Apps & V-Play Games with HockeyApp & V-Play

Testing your mobile game or app before releasing it to the app stores is a crucial task. Not only to find bugs but also to test the app’s user experience, balancing settings or just its long-term fun factor.

Cause of this we are happy to introduce a new plugin for beta testing your apps:

V-Play Qt 5 HockeyApp Plugin

HockeyApp V-Play

This post answers the following questions:

How Beta Testing Works

It might be easy to provide test versions to your colleagues within your company or team. But it is definitely hard to set up a deployment process to provide external testers with new versions. Especially when:

  • You are a single developer also responsible for QA. Your testers then are mostly scattered around the globe and you might only know them via Twitter or your support channels.
  • You or your company is developing a game or app for a customer who wants to test pre-release versions on a regular basis.

For that use cases both Apple and Google have solutions in place. Apple recently acquired TestFlight and offers it within iTunes Connect for beta testing. Google provides alpha and beta stages for your uploaded Google Play Store apps. Both however come with serious drawbacks: Apple requires you to submit your beta apps into their review process. This means you’re losing a lot of time from the upload of your app until it’s on the devices of your testers. Moreover Apple might reject it even before it reaches your testers’ devices. For Play Store beta distribution you need to invite your testers into a Google Group, which requires them to create a Google ID and then to wait some time until it hits the Google Play Store.


So instead of relying on platform-dependent services why not use a service that specializes in beta app distribution? And more, wouldn’t it be great if there would be such a service for Qt-based apps?

Say Hello to our new V-Play Qt 5 HockeyApp Plugin!


HockeyApp is an app distribution service for mobile beta app distribution. In comparison to Apple or Google it’s not bound to a specific platform. Instead it provides the functionality across iOS, Android and Windows Phone 8, a great match with the V-Play cross-platform philosophy.

Thanks to our new plugin it’s really easy to integrate HockeyApp’s functionality into your Qt or V-Play app or game, both for iOS and Android.

How Does HockeyApp Support Beta Testing?

As soon as you have a new app version ready for testing you can upload your build to HockeyApp and optionally notify your testers via email about the new version. The next time your testers open your app on their devices an alert notifies your testers about a new version of your app. You can even show release notes if you want.

Your testers can then update your app over-the-air without downloading any extra files to their computers. When you open HockeyApp’s dashboard you also get some insights how many and who of your users already are on the latest version and which devices they are using for tests.

HockeyApp Dashboard

How Can I Integrate HockeyApp to my Qt 5 App?

If you’ve ever added one of our other Qt 5 plugins to your app you already know how to do it:

  1. Download the HockeyApp plugin. You can either purchase it as a standalone plugin for one app. Or you go for a V-Play subscription and can use it for an unlimited amount of apps and games. There is also a test project available on GitHub which you can use for testing.
  2. After installation you can add it to your code like this:
import VPlayPlugins.hockeyapp 1.0

GameWindow {
  HockeyApp {
    appId: "<HOCKEYAPP-APP-ID>"

The appId lets the plugin know which app it should use for updates. You can create a new app for beta distribution after registering at http://hockeyapp.net/.

For every new release of your project you can then follow these 3 steps:

Increase The App Version Number

HockeyApp identifies app updates by the version number of your uploaded builds. For a new update you therefore need to increase the number.

On iOS, you can set a new version number in your project’s Info.plist file:


The CFBundleShortVersionString variable is the version name that is displayed to your users whereas the CFBundleVersion is used internally by HockeyApp to identify a new version.

On Android, set the version number in your project’s AndroidManifest.xml file:

<manifest … android:versionName="0.18" android:versionCode="18" … >

Again, the android:versionName variable is the version name that is displayed to your users whereas the android:versionCode is used internally by HockeyApp to identify a new version.

If you’re using V-Play these files are already in place in your project’s android & ios subfolders, if you’re starting from scratch you first have to copy the autogenerated files from a previous build and add the following lines to your Qt project file:

# iOS
ios {
  # Path to custom Info.plist file
  QMAKE_INFO_PLIST = ios/Project-Info.plist

# Android
android {
  # Path to directory containg custom AndroidManifest.xml file

If you’re developing a V-Play game also make sure to increase the versioncode and versionname properties in your project’s config.json file. This also means that you need a new license key from https://v-play.net/developers/license/.

Create a Release Build

After adapting your project files you can create your beta app binaries. Change the build target in Qt Creator to “iphoneos-clang” or “Android for armeabi (-v7a)” and select the “Release” build type.

Select Qt Build Target

When using V-Play also make sure to set the “stage” property to “publish” within your project’s config.json file.

This is also a good time to add all your QML files to a resource file and disable the deployment folder, otherwise your source files are shipped as plain text files to your testers. V-Play makes changing from QML files with DEPLOYMENTFOLDERS to resources very easy: you do not need to change any paths in your QML logic, as V-Play does this automatically for you. For more details what steps are involved at changing, and why it is beneficial to only switch to resources at publishing, see here.

Build And Upload The Binaries for HockeyApp

As the last step, you can now build the binaries. Depending on your target platform follow these steps:


  1. Clean your project, select “Run qmake” from Qt Creator’s “Build” menu and open the resulting Xcode project from the shadow build directory
  2. Select your distribution provisioning profile for the “release” build type (you probably have to create a new one at https://developer.apple.com/account/)
  3. Run the “Archive” option from the “Build” menu from within Xcode
  4. Upload the resulting build to HockeyApp.

You can either upload a build manually on the HockeyApp dashboard or a lot easier, you can use the HockeyApp Desktop. Just make sure to open the app before creating your build, as soon as the “Archive” built steps succeeded, HockeyApp then asks you if it should upload the newly created build.

HockeyApp Mac OS X App


  1. Add signing settings to your project within Qt Creator’ Projects settings:
    Qt Creator Android Signing Settings
  2. Clean your project, select “Run qmake” from Qt Creator’s “Build” menu and finally build the app
  3. Upload the resulting APK file to HockeyApp with the help of the HockeyApp desktop app or on the dashboard. The APK file can be found at “<shadowbuild-dir>/android-build/bin/QtApp-release.apk”.

Congrats! The next time your testers open your beta app they get notified about latest uploaded version and can install it over the air.

Get Started with HockeyApp

That’s all you need to know to get started with V-Play’s HockeyApp Plugin!

You can now begin by installing the plugin like described here. The plugin is included in your V-Play Indie subscription plan & above for your V-Play games or as a standalone Qt 5 plugin for your Qt apps. It is available both for iOS & Android apps.

For an easy start you can download our sample project from GitHub, which already comes pre-configured for HockeyApp. Just replace the app identifiers in AndroidManifest.xml & Project-Info.plist, add your own HockeyApp app id and you’re ready to go!


Download HockeyApp Now


For further information have a look at our official documentation and ask your questions in our support forums.

The post Beta Distribution For Mobile Qt Apps & V-Play Games with HockeyApp & V-Play appeared first on V-Play Game Engine.

Introducing video filters in Qt Multimedia

Qt Multimedia makes it very easy to get a video stream from the camera or a video file rendered as part of your application’s Qt Quick scene. What is more, its modularized backend and video node plugin system allows to provide hardware accelerated, zero copy solutions on platforms where such an option is available. All this is hidden from the applications when using Qt Quick elements like Camera, MediaPlayer and VideoOutput, which is great. But what if you want to do some additional filtering or computations on the video frames before they are presented? For example because you want to transform the frame, or compute something from it, on the GPU using OpenCL or CUDA. Or because you want to run some algorithms provided by OpenCV. Before Qt 5.5 there was no easy way to do this in combination with the familiar Qt Quick elements. With Qt 5.5 this is going to change: say hello to QAbstractVideoFilter.

QAbstractVideoFilter serves as a base class for classes that are exposed to the QML world and are instantiated from there. They are then associated with a VideoOutput element. From that point on, every video frame the VideoOutput receives is run through the filter first. The filter can provide a new video frame, which is used in place of the original, calculate some results or both. The results of the computation are exposed to QML as arbitrary data structures and can be utilized from Javascript. For example, an OpenCV-based object detection algorithm can generate a list of rectangles that is exposed to QML. The corresponding Javascript code can then position some Rectangle elements at the indicated locations.

Let’s see some code

    import QtQuick 2.3
    import QtMultimedia 5.5
    import my.cool.stuff 1.0

    Item {
        Camera {
            id: camera
        VideoOutput {
            source: camera
            anchors.fill: parent
            filters: [ faceRecognitionFilter ]
        FaceRecognizer {
            id: faceRecognitionFilter
            property real scaleFactor: 1.1 // Define properties either in QML or in C++. Can be animated too.
            onFinished: {
                console.log("Found " + result.rects.length + " faces");
                ... // do something with the rectangle list

The new filters property of VideoOutput allows to associate one or more QAbstractVideoFilter instances with it. These are then invoked in order for every incoming video frame.

The outline of the C++ implementation is like this:

QVideoFilterRunnable *FaceRecogFilter::createFilterRunnable()
    return new FaceRecogFilterRunnable(this);
QVideoFrame FaceRecogFilterRunnable::run(QVideoFrame *input, const QVideoSurfaceFormat &surfaceFormat, RunFlags flags)
    // Convert the input into a suitable OpenCV image format, then run e.g. cv::CascadeClassifier,
    // and finally store the list of rectangles into a QObject exposing a 'rects' property.
    emit m_filter->finished(result);
    return *input;
int main(..)
    qmlRegisterType<FaceRecogFilter>("my.cool.stuff", 1, 0, "FaceRecognizer");

Here our filter implementation simply passes the input video frame through, while generating a list of rectangles. This can then be examined from QML, in the finished signal handler. Simple and flexible.

While the registration of our custom filter happens from the main() function in the example, the filter can also be provided from QML extension plugins, independently from the application.

The QAbstractVideoFilterQVideoFilterRunnable split mirrors the approach with QQuickItem – QSGNode. This is essential in order to support threaded rendering: when the Qt Quick scenegraph is using its threaded render loop, all rendering (the OpenGL operations) happen on a dedicated thread. This includes the filtering operations too. Therefore we have to ensure that the graphics and compute resources live and are only accessed on the render thread. A QVideoFilterRunnable always lives on the render thread and all its functions are guaranteed to be invoked on that thread, with the Qt Quick scenegraph’s OpenGL context bound. This makes creating filters relying on GPU compute APIs easy and painless, even when OpenGL interop is involved.

GPU compute and OpenGL interop

All this is very powerful when it comes to avoiding copies of the pixel data and utilizing the GPU as much as possible. The output video frame can be in any supported format and can differ from the input frame, for instance a GPU-accelerated filter can upload the image data received from the camera into an OpenGL texture, perform operations on that (using OpenCL – OpenGL interop for example) and provide the resulting OpenGL texture as its output. This means that after the initial texture upload, which is naturally in place even when not using any QAbstractVideoFilter at all, everything happens on the GPU. When doing video playback, the situation is even better on some platforms: in case the input is already an OpenGL texture, D3D texture, EGLImage or similar, we can potentially perform everything on the GPU without any readbacks or copies.

The OpenCL-based example that comes with Qt Multimedia demonstrates this well. Shown below running on OS X, the input frames from the video already contain OpenGL textures. All we need to do is to use OpenCL’s GL interop to get a CL image object. The output image object is also based on a GL texture, allowing us to pass it to VideoOutput and the Qt Quick scenegraph as-is.

OpenCL example on OS X

Real-time image transformation on the GPU with OpenCL, running on OS X

While the emboss effect is not really interesting and can also be done with OpenGL shaders using ShaderEffect items, the example proves that integrating OpenCL and similar APIs with Qt Multimedia does not have to be hard – in fact the code is surprisingly simple and yet so powerful.

It is worth pointing out that filters that do not result in a modified image and are not interested in staying in sync with the displayed frames do not have to block until the computation is finished: the implementation of run() can queue the necessary operations without waiting for them to finish. A signal indicating the availability of the computation results is then emitted later, for example from the associated event callback in case of OpenCL. All this is made possible by the thread-awareness of Qt’s signals: the signal emission will work equally well regardless of which thread the callback is invoked on.

CPU-based filtering

Not all uses of video filters will rely on the GPU. Today’s PCs and even many embedded devices are powerful enough to perform many algorithms on the CPU. Below is a screenshot from the finished version of the code snippet above. Instead of faces, we recognize something more exciting, namely Qt logos:

Qt logo recognition with OpenCV in a Qt Quick app

Qt logo recognition with OpenCV and a webcam in a Qt Quick application using Qt Multimedia and Qt Quick Controls.

The application’s user interface is fully QML-based, even the rectangles are actual Rectangle elements. It is shown here running on a desktop Linux system, where the video frames from the camera are provided as YUV image data in system memory. However, it functions identically well on Embedded Linux devices supported by Qt Multimedia, for example the i.MX6-based Sabre SD board. Here comes the proof:

Qt logo recognition with OpenCV on the Sabre SD

The same application, using the on-board MIPI camera

And it just works, with the added bonus of the touch-friendly controls from the Flat style.

The post Introducing video filters in Qt Multimedia appeared first on Qt Blog.

Squish tip of the week: Handling implementation differences between platforms

A great question from our Webinar Q&A session this week: What is the best way to solve implementation differences between platforms (e.g. Windows Vs Unix)?

When dealing with cross-platform applications, for example Java or Qt, the majority of your Squish tests are not impacted by the platform, as your application, and it’s controls/widgets are identical across platforms. Occasionally however differences may exist.

Using Squish there’s an easy way to handle platform differences: Identify and branch for differences

Example working with Java Applications

You can try it using our sample Addressbook application, located in:

In the following script (javascript), lines 12 and 13 are valid for Linux and Windows, but not valid for Mac:

function main() {
    activateItem(waitForObjectItem(":Address Book_javax.swing.JMenuBar", "File"));
    activateItem(waitForObjectItem(":File_javax.swing.JMenu", "New..."));
    activateItem(waitForObjectItem(":Address Book - Unnamed_javax.swing.JMenuBar", "Edit"));
    activateItem(waitForObjectItem(":Edit_javax.swing.JMenu", "Add..."));
    type(waitForObject(":Address Book - Add.Forename:_javax.swing.JTextField"), "jane");
    type(waitForObject(":Address Book - Add.Surname:_javax.swing.JTextField"), "smith");
    type(waitForObject(":Address Book - Add.Email:_javax.swing.JTextField"), "jane@smith.com");
    type(waitForObject(":Address Book - Add.Phone:_javax.swing.JTextField"), "123.123.1234");
    clickButton(waitForObject(":Address Book - Add.OK_javax.swing.JButton"));
    activateItem(waitForObjectItem(":Address Book - Unnamed_javax.swing.JMenuBar", "File"));
    activateItem(waitForObjectItem(":File_javax.swing.JMenu", "Quit"));
    clickButton(waitForObject(":Address Book.No_JButton"));

To accommodate the platform difference we’ll:

  1. Check the platform prior to the impacted steps
  2. Branch the script to take one path when the platform is Mac, and another path it isn’t

Which results in the following:

function main() {
    activateItem(waitForObjectItem(":Address Book_javax.swing.JMenuBar", "File"));
    activateItem(waitForObjectItem(":File_javax.swing.JMenu", "New..."));
    activateItem(waitForObjectItem(":Address Book - Unnamed_javax.swing.JMenuBar", "Edit"));
    activateItem(waitForObjectItem(":Edit_javax.swing.JMenu", "Add..."));
    type(waitForObject(":Address Book - Add.Forename:_javax.swing.JTextField"), "jane");
    type(waitForObject(":Address Book - Add.Surname:_javax.swing.JTextField"), "smith");
    type(waitForObject(":Address Book - Add.Email:_javax.swing.JTextField"), "jane@smith.com");
    type(waitForObject(":Address Book - Add.Phone:_javax.swing.JTextField"), "123.123.1234");
    clickButton(waitForObject(":Address Book - Add.OK_javax.swing.JButton"));
    if (java_lang_System.getProperty("os.name").indexOf("Mac OS") == 0) {
    } else {
        activateItem(waitForObjectItem(":Address Book - Unnamed_javax.swing.JMenuBar", "File"));
        activateItem(waitForObjectItem(":File_javax.swing.JMenu", "Quit"));
    clickButton(waitForObject(":Address Book.No_JButton"));

Notice, line 12 in the modified script retrieves the platform where the application is *currently* executing. This is important, as the test may be triggered by a remote system using another platform.

Example working with Qt Applications

You can try it using our sample Addressbook application, located in:

In the following script (javascript), lines 10 and 11 are valid for Linux and Windows, but not valid for Mac:

function main() {
    clickButton(waitForObject(":Address Book.New_QToolButton"));
    clickButton(waitForObject(":Address Book - Unnamed.Add_QToolButton"));
    type(waitForObject(":Forename:_LineEdit"), "jane");
    type(waitForObject(":Surname:_LineEdit"), "smith");
    type(waitForObject(":Email:_LineEdit"), "jane@smith.com");
    type(waitForObject(":Phone:_LineEdit"), "123.123.1234");
    clickButton(waitForObject(":Address Book - Add.OK_QPushButton"));
    activateItem(waitForObjectItem(":Address Book - Unnamed_QMenuBar", "File"));
    activateItem(waitForObjectItem(":Address Book - Unnamed.File_QMenu", "Quit"));
    clickButton(waitForObject(":Address Book - Delete.No_QPushButton"));

To accommodate the platform difference we’ll:

  1. Check the platform prior to the impacted steps
  2. Branch the script to take one path when the platform is Mac, and another path it isn’t

Unlike in Java, where the host platform is available with the java_lang_System.getProperty(“os.name”) statement, for Qt the platform should be passed to the squishrunner service when started.

For example, you may start your squishserver using the following commands:
export SQUISH_HOST_OS=`uname`

For Windows, use ver instead of uname:

for /f "delims=" %a in ('ver') do @set SQUISH_HOST_OS=%a

Then modify the script as follows:

function getHostOS(){
    myAUT = currentApplicationContext();
    hostOS = myAUT.environmentVariable("SQUISH_HOST_OS");
    return hostOS

function main() {
    clickButton(waitForObject(":Address Book.New_QToolButton"));
    clickButton(waitForObject(":Address Book - Unnamed.Add_QToolButton"));
    type(waitForObject(":Forename:_LineEdit"), "jane");
    type(waitForObject(":Surname:_LineEdit"), "smith");
    type(waitForObject(":Email:_LineEdit"), "jane@smith.com");
    type(waitForObject(":Phone:_LineEdit"), "123.123.1234");
    clickButton(waitForObject(":Address Book - Add.OK_QPushButton"));
    if (getHostOS() == "Darwin"){
    } else{
        activateItem(waitForObjectItem(":Address Book - Unnamed_QMenuBar", "File"));
        activateItem(waitForObjectItem(":Address Book - Unnamed.File_QMenu", "Quit"));
    clickButton(waitForObject(":Address Book - Delete.No_QPushButton"));

Notice, line 3 in the modified script retrieves the platform where the application is *currently* executing using the value set in the environment variable before starting the squish server. This is important, as the test may be triggered by a remote system using another platform.

How to persuade us that you're going to be a good GSoC student

It is that time of the year again, and people are applying for Google Summer of Code positions. It's great to see a big crowd of newcomers. This article explains what sort of students are welcome in GSoC from the point of view of Trojitá, a fast Qt IMAP e-mail client. I suspect that many other projects within KDE share my views, but it's best to ask them. Hopefully, this post will help students understand what we are looking for, and assist in deciding what project to work for.

Finding a motivation

As a mentor, my motivation in GSoC is pretty simple — I want to attract new contributors to the project I maintain. This means that I value long-term sustainability above fancy features. If you are going to apply with us, make sure that you actually want to stick around. What happens when GSoC terminates? What happens when GSoC terminates and the work you've been doing is not ready yet? Do you see yourself continuing the work you've done so far? Or is it going to become an abandonware, with some cash in your pocket being your only reward? Who is going to maintain the code which you worked hard to create?

Selecting an area of work

This is probably the most important aspect of your GSoC involvement. You're going to spend three months of full time activity on some project, a project you might have not heard about before. Why are you doing this — is it only about the money, or do you already have a connection to the project you've selected? Is the project trying to solve a problem that you find interesting? Would you use the results of that project even without the GSoC?

My experience shows that it's best to find a project which fills a niche that you find interesting. Do you have a digital camera, and do you think that a random photo editor's interface sucks? Work on that, make the interface better. Do you love listening to music? Maybe your favorite music player has some annoying bug that you could fix. Maybe you could add a feature to, say, synchronize the playlist with your cell phone (this is just an example, of course). Do you like 3D printing? Help improve an existing software for 3D printing, then. Are you a database buff? Is there something you find lacking in, e.g., PostgreSQL?

Either way, it is probably a good idea to select something which you need to use, or want to use for some reason. It's of course fine to e.g. spend your GSoC term working on an astronomy tool even though you haven't used one before, but unless you really like astronomy, then you should probably choose something else. In case of Trojitá, if you have been using GMail's web interface for the past five years and you think that it's the best thing since sliced bread, well, chances are that you won't enjoy working on a desktop e-mail client.

Pick something you like, something which you enjoy working with.

Making a proposal

An excellent idea is to make yourself known in advance. This does not happen by joining the IRC channel and saying "I want to work on GSoC", or mailing us to let us know about this. A much better way of getting involved is through showing your dedication.

Try to play with the application you are about to apply for. Do you see some annoying bug? Fix it! Does it work well? Use the application more; you will find bugs. Look at the project's bug tracker, maybe there are some issues which people are hitting. Do you think that you can fix it? Diving into bug fixing is an excellent opportunity to get yourself familiar with the project's code base, and to make sure that our mentors know the style and pace of your work.

Now that you have some familiarity with the code, maybe you can already see opportunities for work besides what's already described on the GSoC ideas wiki page. That's fine — the best proposals usually come from students who have found them on their own. The list of ideas is just that, a list of ideas, not an exhaustive cookbook. There's usually much more what can be done during the course of the GSoC. What would be most interesting area for you? How does it fit into the bigger picture?

After you've thought about the area to work on, now it's time to write your proposal. Start early, and make sure that you talk about your ideas with your prospective mentors before you spend three hours preparing a detailed roadmap. Define the goals that you want to achieve, and talk with your mentors about them. Make sure that the work fits well with the length and style of the GSoC.

And finally, be sure that you stay open and honest with your mentoring team. Remember, this is not a contest of writing a best project proposal. For me, GSoC is all about finding people who are interested in working on, say, Trojitá. What I'm looking for are honest, fair-behaving people who demonstrate willingness to learn new stuff. On top of that, I like to accept people with whom I have already worked. Hearing about you for the first time when I read your GSoC proposal is not a perfect way of introducing yourself. Make yourself known in advance, and show us how you can help us make our project better. Show us that you want to become a part of that "we".

Qt 5.5 Alpha Available

Qt 5.5 is branched from dev and we now have the Alpha packages available. Main focus of Qt 5.5 is to polish and improve existing functionality, but as always there are also some new exciting features to talk about. With Qt 5.5, Canvas 3D is fully supported and a technology preview of long awaited Qt 3D is included. Qt 5.5 also introduces mapping support with a Qt Location technology preview. Qt 5.5 Alpha is the first step towards Qt 5.5 final release planned to be available in May.

Focus on Quality

With many of the previous Qt 5.x releases we introduced new supported platforms and many new modules. With Qt 5.5 we are mainly focusing on polishing and improving existing functionality. Many of the new features are small additions or enabling existing APIs on new platforms. Qt 5 is already a solid platform and we want to make it even better with Qt 5.5.

In addition to Qt functionality, we have been improving our QA and CI systems to be able to better support different configurations. With Qt 5.5, we will have new capabilities in CI and releasing systems enabling us to continue making Qt 5.5.x releases also after Qt 5.6 is released.

Qt 3D and Qt Canvas 3D

One of the most desired new items in Qt 5.5 is a technology preview of Qt 3D 2.0. There has been a lot of effort put into Qt 3D especially by our partner KDAB. The new Qt 3D 2.0 is now shaping up for prime time. Qt has been used throughout the years in making many well known applications leveraging 3D, but Qt 3D makes it easier than before to include and use 3D content in your Qt applications. Qt 3D provides C++ and QML APIs for easy inclusion of 3D graphics into your Qt applications and supports OpenGL 2, 3, 4 and OpenGL ES 2 and ES 3. For more details what Qt 3D 2.0 brings, you can check Qt 3D documentation and the series of blogs by KDAB.

In addition to introducing Qt 3D, Qt 5.5 also brings full support for the new Qt Canvas 3D module. With the lightweight Qt Canvas 3D, it is possible to make WebGL like 3D drawing calls from Qt Quick / JavaScript providing an easy way to use WebGL assets directly on top of Qt Quick. For many 3D needs this is a convenient approach, which allows leveraging of 3D applications developed for HTML5/WebGL.

Qt Location

Another long-awaited module that is now added to Qt 5 is a Technology Preview of Qt Location, adding mapping, geocoding, reverse geocoding, routing and place features to Qt. This makes it is easy to provide mapping functionality in your application. Qt Location supports different mapping providers with backends available for Open Street Map, Mapbox and Here Maps.

Qt Multimedia

Qt Multimedia has received GStreamer 1.0 support and some new features. One of the most interesting new features is a new video filtering framework to integrate frameworks like OpenCV or compute APIs, such as OpenCL or CUDA, with VideoOutput elements. Other additions to Qt Multimedia include, for example, a new API to control viewfinder settings and improved camera support on iOS.

Qt Quick and Qt Quick Controls

Qt 5.5 introduces a new TreeView control and provides the former Enterprise Controls (CircularGauge, DelayButton, Dial, Gauge, PieMenu, StatusIndicator, ToggleButton, Tumbler and TumblerColumn) available also for the open-source users. The former Enterprise Controls are now available via a new QtQuick.Extras import.

Support for threaded rendering using QQuickRenderControl is added. On Windows, Qt Quick rendering now defaults to the threaded Qt Quick render loop when using desktop OpenGL. OS X trackpad functionality is improved to support native pinch gestures via PinchArea, as well as supporting smart zoom.

Qt Quick Engine now supports JavaScript typed arrays and you can now conveniently expose custom C++ value types into the JavaScript environment of QML and QJSEngine. In addition, the Qt Quick Engine has received various performance improvements and optimizations.

Updated Qt WebEngine and Qt WebView

Qt WebEngine is updated to contain a new Chromium version 40 and support for new APIs. Qt WebEngine now provides APIs for managing downloading of files, support for Geolocation, controlling cache and cookies, as well as settings. In addition, many previously experimental Qt Quick APIs are now public and fully supported. Qt WebChannel has been integrated to Chromium IPC making it easier and more secure to create hybrid applications. Qt WebEngine now also provides a new User script API, which together with support for Qt WebChannel provides a powerful combination for making hybrid applications.

Qt WebView now has a native implementation also for Mac OS X (in addition to Android and iOS that were already supported). The Qt WebView has also received new APIs for status notifications, setting HTML content and running JavaScript.

Other New Functionality

Qt Bluetooth now fully supports Bluetooth Low Energy API with also Android and iOS support added in Qt 5.5. We have also introduced classic Bluetooth support on iOS.

Qt Network has received many improvements, for example a new SSL back-end for iOS and OS X based on Secure Transport, support for TLS PSK ciphersuites, and support for elliptic curve certificates. Qt NFC has received neard -based backend for Linux, and QPA has received many improvements.

For more details, please check the full list of New Features in Qt 5.5.

Supported Configurations

In order to better support Qt WebEngine and other functionality benefitting from new compilers, we have updated our CI and releasing systems with new configurations for Qt 5.5. To be able to support the new configurations, we are dropping some older ones (e.g. Ubuntu 11.10 and 12.04 dropped from CI, OS X 10.7 only supported as a secondary platform). Qt 5.5 will provide support for Windows 10 (when available) and RedHat Enterprise Linux 6.6.

For more details on new CI configurations, please check the wiki.

Deprecated Modules

Qt WebKit, Qt Declarative (Qt Quick 1) and Qt Script modules are being deprecated in Qt 5.5. Qt WebEngine is the direct replacement of Qt WebKit, Qt Quick 2 replaces Qt Quick 1 and Qt Script is replaced by the Qt QML functionality. All these modules are still included in the Qt 5.5 release, but considered for removal in the future releases of Qt.

Get Qt 5.5 Alpha

Qt 5.5 Alpha source packages are available via Qt Account and download.qt.io. Binaries will be provided in conjunction with Qt 5.5 Beta release, and binary snapshots will be available before the Beta.

Please help us in making Qt 5.5 awesome. Try out the Qt 5.5 Alpha and report issues to bugreports.qt.io.

The post Qt 5.5 Alpha Available appeared first on Qt Blog.

It’s All About the (Customer) Experience

“The Times They Are a Changin’” – Bob Dylan, 1964

How many of you have noticed a change in the buying behavior of consumers today?

As Bob Dylan so aptly stated more than 50 years ago when major disruptive social change was occurring, change comes with a force that shakes the walls and windows. The times, they are indeed changing. And for everyone in retail today, times they are a changin’ yet again.

Qt 5 Push Notifications with V-Play’s Parse Push Plugin

Push Notifications are a great way to engage with your users. Earlier last year we released our Local Notifications Plugin. The plugin is great for time-triggered actions, especially for timer-based applications. Local notifications however are not working out when you need logic controlled outside of your apps, like it’s done for social games and social networks.

Thus we are happy to announce the release of our Parse Push Plugin for iOS & Android.


Server-side logic for delivering cross-platform push notifications can be hard. Moreover you want to focus on building your app or game, not on back-end code. We therefore choose Facebook’s Parse Push service as push back-end. Parse allows sending push messages through their push web composer or from your own web server via a REST interface.

How Does It Work?

Integrating the plugin is as easy as usual with V-Play and QML:

Parse {
  applicationId: "<PARSE-APP-ID>"
  clientKey: "<PARSE-CLIENT-ID>"

  onNotificationReceived: {
    console.debug("Received new notification")

To learn more about integrating the Parse Push Plugin into your own code read on here:

How To Integrate Push Notifications in Your Apps & Games

Get Parse Plugin

The Parse Push plugin is available for iOS and Android. As with all our plugins the new Parse Push Plugin is included in your V-Play Indie Subscription and above. If you are not a member of the V-Play community you can also use it as a standalone Qt 5 plugin and get it here: plugins.v-play.net/plugins/parse/.

If there are any questions just leave a comment or ask them via our support channels. We are looking forward to your feedback!

To stay up to date with future V-Play plugin announcements and promotions follow @vplayplugins on Twitter and subscribe to the V-Play Plugin Newsletter.

The post Qt 5 Push Notifications with V-Play’s Parse Push Plugin appeared first on V-Play Game Engine.

Fancy dinners, cgroups and namespaces, and meet-ups

Weeks 09 and 10 of 2015 have seen … a presentation at the internet-of-things-flavored Embedded World about “Defensive Strategies in Open Source”, Berlin FSFE fellowship and Open Source meet-ups, farewell dinners, theatre, an interview for a master thesis about organisations influenced by Open Source, a lot of reading and researching about software and patents and EC decisions on competition, the beginning of an office hunt, a very cool presentation on namespaces and cgroups in Linux, and a (very) fancy dinner. And my “2” key isn’t working well :-)

Embedded World is a pretty interesting conference that takes place in Nuremberg in February. Internet of Things seems to be the current motto. Open Source technologies, especially Linux in various incarnations of the stack have become a mainstay in embedded computers. Nicholas McGuire of OSADL organised a one day workshop on “Legal Aspects of Open Source”, where I presented about “Defensive strategies in Open Source – patent non-aggression and the Open Invention Network”.


Miriam Ballhausen of JBB Rechtsanwälte presented right before me about intricacies of Open Source licensing. Our two presentations nicely complemented each other, with me focusing more in what challenges FLOSS communities experience when managing the fine line between collaborating on building base technologies while still competing in the areas that differentiate for their users. One of the claims in my presentation is that the legal implications of using FLOSS gather so much attention because the underlying process changes are rather dramatic and challenge the established legal frameworks that have been designed with the traditional competitive (as opposed to collaborative) way of inventing. There was time for dinner, too. The regional food in Nuremberg is hearty and delicious. Excellent local beer is made there, and Schäufele is my favorite local dish:


When I was back from Nuremberg on Thursday, I had to deal with a rather unpleasant contractual issue with a client. One lesson learned from it is to either bring in the lawyers before a contract is signed and cover all bases, or later handle project issues like grown-ups and settle them between the engineers. Bringing in legal counsel when a project is mostly complete probably just means spending way too much time explaining why things weren’t done by the book, without getting to results. However it looks like the parties are getting their act together and will finally finish the work soon.

On Thursday evening I attended the Berlin FSFE Fellowship meeting. It was right after Jonas Öberg started as the new executive director for FSFE, and it was a chance to meet and congratulate him and to wish him good luck. This marks a development of FSFE to re-organise it’s leadership, by separating the ED’s and the president’s jobs. Endocode just became a FSFE sponsor, Karl wrote about it here.

Before the weekend it was time for Endocode’s partners (aka shareholders) to conduct their monthly management meeting. We, too, are trying to split operational and long-term oriented work with weekly meetings that handle all short-term issues and monthly meetings. It is important to set aside time to focus on more visionary aspects. Otherwise random issues that crop up will always take priority, preventing processes from developing and things from improving. After that, we went to Mirchi in Kreuzberg to bid farewell to ex-colleague and co-KDE-contributor Kevin Funk who is moving away. Just for completeness we finished the week at the Savoy bar with fancy cocktails.

On Saturday we went to see an amateur theatre production by Berlin’s StageInk theatre company. The play was a self-written piece with a ghost-ship story line. The group apparently practised for 18 months to in the end deliver 4 performances — it feels like a waste because it was actually really quite good. More people should see it :-)


Then finally on Sunday the city saw the first Open Source Meetup for 2015, organised by my esteemed colleague Chris. A good mix of contributors and other interested people, discussions about the relations between European languages and kernel multithreading implementations, and good food at Naan.

So started week 10. On Monday Sandra interviewed me for her master’s thesis. She is researching success factors of Open Source companies. Endocode’s philosophy is to a large extend inspired by Open Source culture. The interview was not just a one way flow of information, it was also a chance to reflect on what the motivations and thoughts were at the time, and what came out of them. I drew two conclusions: First, the goals we initially set out for, mostly to create a company that puts individuals at the center and tries to build a place in which they can thrive, have been reached for the most part (which doesn’t mean it is all done, of course). Second, this means that the next challenge is to keep this spirit while the company grows to a size that requires more than ad-hoc organisation. This realisation ties in nicely with the series of strategy workshops we started. Exciting times ahead.

Afternoon reads included Software and Patents in Europe by Philip Leith. I find that book well-research and -reflected. Certainly a recommended read, especially because it does not argue from the Open Source community’s perspective. Sometimes it is more educational to read competing opinions, it helps get out of the self-imposed filter bubble. It was accompanied by European Commission Decisions on Competition, which gives a fascinating overview (if you are into that kind of thing) of the landmark cases of EC rulings on competition.

On Tuesday we started the process of looking for a new office for Endocode. As usual, we moved into our current place with the intention to stay there for 3 to 4 years, and then outgrew it within 18 months. Not that I am complaining. We are now looking for a 300-400qm place in central Berlin, to start the next phase. In the evening at the next Endocode meet-up, Alban presented about the Linux kernel APIs for containers, like cgroups and namespaces. Those are the underlying technologies for many of the things we are currently working on, including CoreOS, Docker and Rocket. Fascinating, if you are an operating system nerd (which deep down, I am), and nothing short of revolutionary.

The rest of the week was not that spectacular, short of a 5 hour meeting attended by phone bridge (the audio quality of these is so bad, my kids have better recording equipment at home :-), and the beginning of a brainstorm for the presentation on March 17. However… the weekend… We spend it in the countryside of Mecklenburg-Vorpommern, at Ich weiss ein Haus am See. The stay was my birthday present to Alex, who is a foodie extraordinaire. The restaurant of the place was one of the first in eastern Germany to receive a Michelin star. Conveniently, Saturday was my birthday, so we had double the reasons to celebrate. The four-course dinner was outstanding from start to finish, and the ambience is just beautiful. We both did not bring computers or phones to dinner, so no food pictures. It is all left to your imagination :-)


Filed under: Coding, CreativeDestruction, English, FLOSS, KDE, OSS, Qt

A QML Quick Reference

I am a strong proponent of quick references or "cheat sheets" as an aid for recalling often-used information. In my career, I have created many work-related reference cards for colleagues and for my own personal use as well as for hobbies such as electronics and retro computing.

New Qt Forum now open

After a long and hard migration, the Qt Forums are up at http://forum.qt.io

This is a quick introduction to what is new on the Qt Forum. I urge you to go and test the site yourself, that is the best way to learn.

Logging in

As with the Qt Wiki, the Qt Forum uses Qt Account for logging in. In practice this means that you need a Qt Account.

To create a Qt Account, you can go to the Qt Forum login page, click on the Qt Account check mark and get directed to the Qt Account login page. There at the bottom of the page, you will find a ‘Create new account’ link.

Your username from qt-project.org has been reserved for your email, so when creating a Qt Account, please use the same email as you did on qt-project.org. This way you will get your own username and have your posting history and reputation intact as you move to Qt Forum.

After creating your Qt Account, you can login to Qt Forum with it and start posting and replying to posts.

On first login the new posts box will show that everything on the site is new. Technically that is true, as everything was just migrated over. You can safely go and mark all topics as read and start your experience fresh.

Reputation and how it works

The Qt Forum replaces the points in the old qt-project.org forums with reputation.

You gain reputation when someone votes your post or reply up. There is a voting element under the title of the post with the tools for being notified of posts, favouriting a post and voting it up or down.

The votes on a post can be used to search for  the most popular answers to a question.

The points from qt-project.org were transferred to the Qt Forum with an adjustment (division by ten) to account for the different mechanism that reputation works with.

At this point, we have set the system so that points only bring you fame and at reputation 500 thread moderation rights. The exact level needs to be checked as we move along, we don’t really know if 500 is a lot or little.

Going forward the points can be used to earn badges and other fun stuff.

Marking posts as solved and other tags

The ‘thread tools’ at the bottom of a thread let the poster or moderators ‘mark a thread as solved’. This will add a ‘Solved’ tag to the post in the category view to help people find solved posts easily.

When you start a new post, you can add tags to it. The tags will help people find the posts that they are interested in. They also help when searching the site.

What the future holds

We just went live after a marathon migration, but already we have some things that need fixing.

First all the badges and groups from the old site need to be brought over. This takes a bit of work, but should be done by next week.

The layout of the Qt Forum needs tweaks, the top level categories should provide more hints on what they contain. And we need to work out what to do with really long category names, now the ends just fade away. Also the login page needs some text editing, as the Qt Account is our only means of logging in.

In terms of functionality, I would like for all us users to first get used to how the Qt Forum works and then start thinking on how to improve the experience.

When you get an idea about what we should really have on the forums, please come over there and post a new topic to Qt.io website category. I’ll be there and we can talk how to improve the Qt Forum.

The post New Qt Forum now open appeared first on Qt Blog.

Qt Creator 3.4 beta1 released

We are happy to announce the release of Qt Creator 3.4 beta1! This release focuses more on bug fixing, polishing and under the hood changes, but nevertheless comes also with a range of new features.

We added auto-completion for the signal and slot parts in Qt 5 style connects, so you usually no longer need to look for the type manually. Just type the “&” and let auto-completion figure it out.

Locator has a new filter, All Included C/C++ Files. It finds all files that are used in your projects by including them, even if they are not explicitly mentioned in your project. The filter is part of the default that is used when you just type in the Locator input field, and shares the shortcut string with Files in Any Project.

Android integration now also supports 64 bit tool chains, and bare metal development can now also be done with generic projects. There have been many more enhancements, please see our change log for a more complete list.

Users of the Professional or Enterprise edition will be happy to hear that we added experimental integration for Qt Test based auto tests and Qt Quick tests. You get another navigation pane Tests, which lists the tests defined in your project, provides ways to run individual or sets of tests, and nicely shows test results in a new Test Results output pane. To try it, open Help > About Plugins (Qt Creator > About Plugins, on OS X), turn on Utilities > AutoTest, and restart Qt Creator.

We also moved the Clang static analyzer integration out of experimental state, and added support for using it in combination with MSVC (you need at least Clang 3.6 for this), and MinGW. You can also suppress individual diagnostics for a file in your project now.

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 also can find us on IRC on #qt-creator on irc.freenode.net, and on the Qt Creator mailing list.

The post Qt Creator 3.4 beta1 released appeared first on Qt Blog.

Qt Weekly #28: Qt and CUDA on the Jetson TK1

NVIDIA’s Jetson TK1 is a powerful development board based on the Tegra K1 chip. It comes with a GPU capable of OpenGL 4.4, OpenGL ES 3.1 and CUDA 6.5. From Qt’s perspective this is a somewhat unorthodox embedded device because its customized Linux system is based on Ubuntu 14.04 and runs the regular X11 environment. Therefore the approach that is typical for low and medium-end embedded hardware, running OpenGL-accelerated Qt apps directly on the framebuffer using the eglfs platform plugin, will not be suitable.

In addition, the ability to do hardware-accelerated computing using CUDA is very interesting, especially when it comes to interoperating with OpenGL. Let’s take a look at how CUDA code can be integrated with a Qt-based application.

Jetson TK1

The board

Building Qt

This board is powerful enough to build everything on its own without any cross-compilation. Configuring and building Qt is no different than in any desktop Linux environment. One option that needs special consideration however is -opengl es2 because Qt can be built either in a GLX + OpenGL or EGL + OpenGL ES configuration.

For example, the following configures Qt to use GLX and OpenGL:

configure -release -nomake examples -nomake tests

while adding -opengl es2 requests the usage of EGL and OpenGL ES:

configure -release -opengl es2 -nomake examples -nomake tests

If you are planning to run applications relying on modern, non-ES OpenGL features, or use CUDA, then go for the first. If you however have some existing code from the mobile or embedded world relying on EGL or OpenGL ES then it may be useful to go for #2.

The default platform plugin will be xcb, so running Qt apps without specifying the platform plugin will work just fine. This is the exact same plugin that is used on any ordinary X11-based Linux desktop system.

Vsync gotchas

Once the build is done, you will most likely run some OpenGL-based Qt apps. And then comes the first surprise: applications are not synchronized to the vertical refresh rate of the screen.

When running for instance the example from qtbase/examples/opengl/qopenglwindow, we expect a nice and smooth 60 FPS animation with the rendering thread throttled appropriately. This unfortunately isn’t the case. Unless the application is fullscreen. Therefore many apps will want to replace calls like show() or showMaximized() with showFullScreen(). This way the thread is throttled as expected.

A further surprise may come in QWidget-based applications when opening a popup or a dialog. Unfortunately this also disables synchronization, even though the main window still covers the entire screen. In general we can conclude that the standard embedded recommendation of sticking to a single fullscreen window is very valid for this board too, even when using xcb, although for completely different reasons.


After installing CUDA, the first and in fact the only challenge is to tackle the integration of nvcc with our Qt projects.

Unsurprisingly, this has been tackled by others before. Building on this excellent article, the most basic integration in our .pro file could look like this:

... # QT, SOURCES, HEADERS, the usual stuff 

CUDA_SOURCES = cuda_stuff.cu

CUDA_DIR = /usr/local/cuda
CUDA_ARCH = sm_32 # as supported by the Tegra K1

LIBS += -L $$CUDA_DIR/lib -lcudart -lcuda
osx: LIBS += -F/Library/Frameworks -framework CUDA

cuda.commands = $$CUDA_DIR/bin/nvcc -c -arch=$$CUDA_ARCH -o ${QMAKE_FILE_OUT} ${QMAKE_FILE_NAME}
cuda.dependency_type = TYPE_C
cuda.depend_command = $$CUDA_DIR/bin/nvcc -M ${QMAKE_FILE_NAME}
cuda.input = CUDA_SOURCES
cuda.output = ${QMAKE_FILE_BASE}_cuda.o

In addition to Linux this will also work out of the box on OS X. Adapting it to Windows should be easy. For advanced features like reformatting nvcc’s error messages to be more of Creator’s liking, see the article mentioned above.

A QOpenGLWindow-based application that updates an image via CUDA on every frame could now look something like the following. The approach is the same regardless of the OpenGL enabler in use: QOpenGLWidget or a custom Qt Quick item would operate along the same principles: call cudaGLSetGLDevice when the OpenGL context is available, register the OpenGL resources to CUDA, and then do map – invoke CUDA kernel – unmap – draw on every frame.

Note that in this example we are using a single pixel buffer object. There are other ways to do interop, for example we could have registered the GL texture, got a CUDA array out of it and bound that either to a CUDA texture or surface.

// functions from cuda_stuff.cu
extern void CUDA_init();
extern void *CUDA_registerBuffer(GLuint buf);
extern void CUDA_unregisterBuffer(void *res);
extern void *CUDA_map(void *res);
extern void CUDA_unmap(void *res);
extern void CUDA_do_something(void *devPtr, int w, int h);

class Window : public QOpenGLWindow, protected QOpenGLFunctions
    void initializeGL();
    void paintGL();

    QSize m_imgSize;
    GLuint m_buf;
    GLuint m_texture;
    void *m_cudaBufHandle;


void Window::initializeGL()

    QImage img("some_image.png");
    m_imgSize = img.size();
    img = img.convertToFormat(QImage::Format_RGB32); // BGRA on little endian
    glGenBuffers(1, &m_buf);
    glBindBuffer(GL_PIXEL_UNPACK_BUFFER, m_buf);
    glBufferData(GL_PIXEL_UNPACK_BUFFER, m_imgSize.width() * m_imgSize.height() * 4, img.constBits(), GL_DYNAMIC_COPY);
    glBindBuffer(GL_PIXEL_UNPACK_BUFFER, 0);

    m_cudaBufHandle = CUDA_registerBuffer(m_buf);

    glGenTextures(1, &m_texture);
    glBindTexture(GL_TEXTURE_2D, m_texture);

    glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, m_imgSize.width(), m_imgSize.height(), 0, GL_BGRA, GL_UNSIGNED_BYTE, 0);


void Window::paintGL()

    void *devPtr = CUDA_map(m_cudaBufHandle);
    CUDA_do_something(devPtr, m_imgSize.width(), m_imgSize.height());

    glBindBuffer(GL_PIXEL_UNPACK_BUFFER, m_buf);
    glBindTexture(GL_TEXTURE_2D, m_texture);
    // Fast path due to BGRA
    glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, m_imgSize.width(), m_imgSize.height(), GL_BGRA, GL_UNSIGNED_BYTE, 0);
    glBindBuffer(GL_PIXEL_UNPACK_BUFFER, 0);

    ... // do something with the texture

    update(); // request the next frame

The corresponding cuda_stuff.cu:

#include <stdio.h>
#ifdef Q_OS_MAC
#include <OpenGL/gl.h>
#include <GL/gl.h>
#include <cuda.h>
#include <cuda_gl_interop.h>

void CUDA_init()
    cudaDeviceProp prop;
    int dev;
    memset(&prop, 0, sizeof(cudaDeviceProp));
    prop.major = 3;
    prop.minor = 2;
    if (cudaChooseDevice(&dev, &prop) != cudaSuccess)
        puts("failed to choose device");
    if (cudaGLSetGLDevice(dev) != cudaSuccess)
        puts("failed to set gl device");

void *CUDA_registerBuffer(GLuint buf)
    cudaGraphicsResource *res = 0;
    if (cudaGraphicsGLRegisterBuffer(&res, buf, cudaGraphicsRegisterFlagsNone) != cudaSuccess)
        printf("Failed to register buffer %u\n", buf);
    return res;

void CUDA_unregisterBuffer(void *res)
    if (cudaGraphicsUnregisterResource((cudaGraphicsResource *) res) != cudaSuccess)
        puts("Failed to unregister resource for buffer");

void *CUDA_map(void *res)
    if (cudaGraphicsMapResources(1, (cudaGraphicsResource **) &res) != cudaSuccess) {
        puts("Failed to map resource");
        return 0;
    void *devPtr = 0;
    size_t size;
    if (cudaGraphicsResourceGetMappedPointer(&devPtr, &size, (cudaGraphicsResource *) res) != cudaSuccess) {
        puts("Failed to get device pointer");
        return 0;
    return devPtr;

void CUDA_unmap(void *res)
    if (cudaGraphicsUnmapResources(1,(cudaGraphicsResource **) &res) != cudaSuccess)
        puts("Failed to unmap resource");

__global__ void run(uchar4 *ptr)
    int x = threadIdx.x + blockIdx.x * blockDim.x;
    int y = threadIdx.y + blockIdx.y * blockDim.y;
    int offset = x + y * blockDim.x * gridDim.x;


void CUDA_do_something(void *devPtr, int w, int h)
    const int blockSize = 16; // 256 threads per block
    run<<<dim3(w / blockSize, h / blockSize), dim3(blockSize, blockSize)>>>((uchar4 *) devPtr);

This is all that’s needed to integrate the power of Qt, OpenGL and CUDA. Happy hacking!

The post Qt Weekly #28: Qt and CUDA on the Jetson TK1 appeared first on Qt Blog.

Qt Forum migration coming up

Heads up everyone, Qt Forum migration approaching.

We will be doing the Qt Forum migration tomorrow, 4th March 2015.

The timeline for the migration is set so that around 9 o’clock CET we’ll be taking the forums to a read-only state and then start migrating the content. The migration has taken over five hours in the test runs that have been done, so you can count on a full day of no new posts or replies.

During the migration the old forums will be visible and searchable, you just won’t be able to post to them. This is to have a clean migration, with no loose threads left on the old system.

Once the content has been migrated, the old forums will be left in a read-only state, and redirects will be set up from the category and thread level to point to the new forum. The redirects are essential for search engines, quite a lot of the viewer traffic to the forums comes from different search engines.

In the new forums, the login system will be Qt Account.

We had an issue in the Qt Account registration page, where all the fields were marked as mandatory, that was an error, and now the fields have been set as optional, as they should be. Sorry about that.

The new forums will be in the style of qt.io. Functionally the forum will be more modern, with voting on replies and topics coming right out of the box. Also topic tagging will be there right away.

The new forum is based on NodeBB, is a modern actively developed platform, that has a good plugin system in place. There are many plugins available and if we really need something specific for the Qt Forums, there is the possibility to write a new one. The platform itself is being developed all the time, so we can also expect new features when new versions are released.

Of course the basics will all be like they were, posting new threads, replying to threads and the familiar structure of sub-forums.

I’m really looking forward to seeing the new Qt Forum in action.

But first we need to do the migration tomorrow.

The post Qt Forum migration coming up appeared first on Qt Blog.

Internet of Things: Living in the Periphery of User Attention

When designing a user experience, we usually assume we are engaging a user’s center of attention, albeit short. We design an experience that will be a user’s primary focus or foreground activity for the duration of their engagement with a device, whether it be on a desktop, laptop, phone or tablet.

Coding for fun: A Facebook Photo Connection Graph

Apparently I haven’t blogged in nearly 5 years, wow! Most of my coding for fun in the last few years ended up being on internal systems to my previous company. Well all that’s in the past now, I’m about to start an adventure of traveling for 6 months around Central/South America and South-east Asia.

But just before that, had a couple days downtime so thought I would learn a little javascript and D3. You can see the result on:

(works in Chrome/Firefox, you have to click ‘Accept’ on the Facebook popup)

Basically it will give you a graph visualisation of who you are tagged with on Facebook, and how your friend tags relate — at least all the ones available from the Facebook graph UI.

You can use the date slider at the top to restrict the timeline — it’s interesting to see how people come and go in your life, at least as far as Facebook photos are concerned.

Looking forward to future fun coding, maybe more directly in an established free software project again!

Facebook Photo Tag Graph




Qt @ Embedded World 2015

Yesterday, we ended a great 3 days at Embedded World 2015 (Feb 24-26)  in Nuremberg, Germany. Considered the largest embedded development trade show, the event organizers estimated 30,000 exhibition visitors, over 1,500 congress participants and around 900 exhibitors from over 35 countries.

Personally, this is my 7th Embedded World with Qt and I have to say that this one has been our best one yet. I know, I say that every year, but the good thing is that we keep getting better every year; larger booth, more demos, more visitors, more companies sold on the fact that Qt is the best solution for embedded software development.

We showcased Qt’s strength in embedded software development with a combination of demos and customer projects focused on Qt in Automotive, Qt in Automation, Qt in IoT, all telling/showing the story of how Qt is used in a real-life reference project or product. Qt’s role in embedded software development was further told by our “Under the Hood” demos highlighting several specific features and functions such as:

  • Qt and OpenCV: Demonstrating how to easily & efficiently integrate computer vision or other computation or image processing algorithms with Qt Quick 2 and Qt Multimedia.
  • Qt Creator in Action – Debugging and profiling: Demonstrating the power of Qt Creator IDE for one-click embedded deployment, and on-device debugging and profiling, Qt Quick Designer
  • Qt UI capabilities, Qt WebEngine, Virtual Keyboard, multimedia capabilities, etc.
  • Qt for QNX: Qt 5 applications and UIs on QNX Neutrino
  • Qt for VxWorks: Qt 5 applications and UIs on VxWorks 7

This year, we had, like in the past 3 years, the live coding theater running daily on the hour from 10:00-16:00. We mixed it up this year with 3 different sessions: Introduction to Device Creation with Qt, Functionality Meets Productivity – Qt Developer Tools and Qt Features Overview. Thanks to our fearless and dedicated presenters. Well done!

I was the most happiest to have a large portion of our booth demos come from our Qt Partners. They had an abundance of industry-specific demos in automotive, automation and IoT. Qt’s story was made stronger with our partners demonstrating the power of Qt and its many uses in the embedded space. Thanks to e-Gits, basysKom, Froglogic, KDAB, Adeneo Embedded and ICS for being with us.

Without more hoopla, below are a few pictures from our booth and demos. If you came by our booth, thanks for visiting us! I would also like to say Thank You to The Qt Company staff onsite and again to our partners. Until next year.



Qt Embedded World 2015 Qt Embedded World 2015 Live coding theater - Qt Embedded World 2015 Qt Embedded World 2015 Qt in Medical & Qt in Marine Navigatiion Qt Machine Vision - OpenCV Nautical UI - Qt Partner KDAB Testing tool -Qt Partner Froglogic Automation - Qt Partner basysKom Automotive - Qt Partner - e-Gits Automotive - Qt Partner ICS Automotive - Qt Partner Adeneo Embedded Automotive - Qt on Magneti Marelli

The post Qt @ Embedded World 2015 appeared first on Qt Blog.

New Qt Wiki Now Available

We are continuing our site unification to qt.io and we have now migrated the content from qt-project.org and today opened up the new Qt Wiki under qt.io. We invite all of you to start editing the new Qt Wiki under qt.io using the new MediaWiki implementation.

This is the first phase launch of the wiki under its new home, and therefore, you may find some things currently missing or not quite like they were before under qt-project.org. There are a variety of reasons for the latter. One main one is that our goal has been to make things easier than they have been before, providing wiki users a better editing experience, as well as more flexibility.

MediaWiki is is one of the standard wiki formats, which is a more familiar format to use for many than the wiki that has been used under qt-project.org.

MediaWiki benefits:

  • Open source platform
  • Active development of the platform
  • A wide range of plugins to extend the wiki functionality
  • Version control
  • Better tools to follow and automate working on the wiki

What you will find different

In this new wiki, we will all be able to keep track of active editors directly in MediaWiki where it will be easier to follow who has edited what and when, as well have better control of versions.. Unfortunately, in this first phase, you will notice that the edit history of past articles has not been migrated over. As the old wiki system (Expression Engine) and MediaWiki are very different it has proven very difficult for the migration team to combine history from the old system into the new one. Our team will continue to look at this as we move along to see how we can best manage this. However, we do feel that manage wiki posts and edits from now and in the future will be much better, which outweighs in part the possible loss of past article history.

Using Qt Account for editing

The biggest change that the wiki introduction brings to you as a user, is that we are moving to using Qt Account as the identity and login service for the wiki.

Qt Account is in essence the gateway to what we are building as a new Qt developer portal. We have already started using it for commercial evaluators and customers in the past year. Currently, the Qt Account web portal provides users with license information, account and payment options. It is also provides access to The Qt Company Support Center where commercial users can submit support issues.

This is just the beginning, however. Our goal is to add valuable Qt information and resources, early access benefits, programs and the like into the Qt Account developer portal, making it your one-stop-shop for up-to-date Qt info and goodies.
I’ll say something in big bold letters here:

When you start to edit, you will need to create a Qt Account. Please make sure to use the same email as you had on qt-project.org, that way you will get your nickname to come along with you.

Previously you logged into the wiki with your qt-project.org account details. Now you will be directed to the Qt Account login page.

If you do not yet have a Qt Account, you can create an account from the login page. If you have been active on qt-project.org, your username has been reserved for you, if you use the same e-mail address as on qt-project.org.

Our next item to migrate over is the Forums. When they move, they will also use Qt Account for login services. This is also the reason to use the same email on Qt Account as you did in qt-project.org. When the forums migrate under qt.io, your nickname and posts will move with you. However, please note that if you use a different email, we can’t connect your nickname automatically.

Migrated content

The old wiki contained over 3000 pages, which were processed and migrated to the new wiki. Some of the pages are quite old, but we know people work on old platforms and with old software releases, so we didn’t intentionally delete pages.

Some old pages were not migrated, but that decision was based on browsing data. If the page had very low, or no, visitors in the past year, it was deemed to be of low value and sadly left behind.

As with any migration there are some few issues. We are aware of challenges in at least the following:

  • Image links are broken.
  • Code blocks have been split into parts
  • Special characters have been encoded as HTML character codes
  • The way Category pages used to work is not the way MediaWiki works, so some Category pages contain double information

Therefore, we would be grateful if you could help us with the following:

Cleaning up the content

If you maintain or edit a page(s), please have a look next time when you edit to see whether there are issues on the page. Open the same page on the old wiki and take a look if something is missing or if it looks wrong, and please fix it.

We opened a wiki page where you can mark your page updated. Once you have looked at a page and edited it to an up-to-date state, please take a minute to add it tothe page list here. (I will be looking at the page edits and updating the page, but I do appreciate if you help me out there)

A helpful page that the wiki itself provides is the list of pages with broken links. If you can help out, you can go through the pages listed there and grab the content/links from the old wiki and upload it to the new wiki. We now have proper image uploading in the new wiki, a great new benefit. Also if you do not wish to upload images to the Qt Wiki, we enabled linking to external images, by just pasting the direct image link to the wiki text, this should be practical for logos and images which may change.

Also, if your favourite page did not make it to the new wiki due to very low visitor count in the past year, we encourage you to re-create the page on the new wiki.

Old wiki still available

The old wiki will stay open for reading until the end of March. That means that you have a month to make sure your favourite pages have not lost content in the move.

After that, the old wiki will be retired and redirects will be set in place.

We really appreciate your help in cleaning up the content and also welcome your feedback. It is lots of content, so we can’t do it alone. Thanks for your help and support!

The post New Qt Wiki Now Available appeared first on Qt Blog.

Important Qt-project.org Migration to qt.io Info

Today, we will go live with the new Qt Wiki on qt.io with content migrated from qt-project.org. Before we do that and as we reach a major milestone in this migration project, I wanted to explain a bit on what are the biggest changes you will see with this overall migration project and what it means to you and also new functionality and things to expect in the future.

The biggest changes you will see are:

  • The current gamification, points system from qt-project.org (DevNet) will change
  • “Qt Account” will be the new login service to access and edit the wiki and forums
  • The services will be on new platforms

Different point system

As we change the wiki and forum platforms, some things will change.

One of these is the current points and levels system. In the new site, we will not use one point system to denote your activity within the qt.io site. Instead, each service (wiki & forum) will have their own lists of activity.

In the forums, which have been the main source of points in qt-project.org, the new system has a Reputation score, which works more based on people liking posts and answers, a more people-centric approach. Initially, there won’t be point levels. As we move along, we will introduce other features and possible programs to allow for more interaction.

A great thing about the new system is that it provides badges and groups, which allow us to have many types of engagement and recognition-based on forum activities. We will migrate the badges from the old system, so those won’t be lost. However, as it is a big task, those will not be there on the first day we switch over to the new forum. (BTW: we are estimating that the migration will happen sometime next week. But, please bear with me, as some things in the technical world are just beyond our control.) The new forum will provide a more flexible badge system overall, so we will be working more with badges in the future.

In the new wiki, the system will keep track of who edits and creates pages and keeps lists based on that. The main difference is that these statistics will not be directly added to an overall point system, at this point.

To sum it up, in the future there won’t be designations like ‘Ant farmer’, but you will have a reputation score on the forum and an edit history on the wiki. The main goal of knowing who is an active community member will be met; the way it is done will be slightly different giving us more flexibility to add more interaction possibilities as we move along and as we hear feedback and ideas from the community.

As mentioned, we do have plans of a new overall unified-level point program system, where those that are truly active within our channels will benefit greatly. This will span both commercial and open source users where the goal is to connect to all our users and provide valuable interactive information. However, this is still in the planning stages and we will communicate those as we move along. For now, our updated services like wiki and forums will have their own point system and history overview.

Profiles & Qt Account as your login service

One of the biggest changes for you as a user is that we are moving to using Qt Account as the identity and login service for the new wiki and forums in qt.io. The logic to having a single service for logging in is simple; no need to have separate logins for different services.

If you currently have a user profile under qt-project.org, your personal information contained in it, such as detailed contact information and social media accounts, will unfortunately not be migrated over at this time. We will, however, migrate and match all existing nicknames/usernames from the current system and peg it to your Qt Account. We are not throwing that information away, if at some point in the future we enhance the Qt Account profile to include the data, it can be added from the qt-project.org database we are keeping in backups.

Qt Account is in essence the gateway to what we are building as a new Qt developer portal. We have already started using it for commercial evaluators and customers in the past year. Currently, the Qt Account web portal provides users with license information, account and payment options. It is also provides access to The Qt Company Support Center where commercial users can submit support issues.

This is just the beginning, however. Our goal is to add valuable Qt information and resources, early access benefits, programs and the like into the Qt Account developer portal, making it your one-stop-shop for up-to-date Qt info and goodies.

IMPORTANT: Please make sure to use the same email address as you had on qt-project.org, that way you will get your nickname to come along with you to Qt Account and the new services.

New look and feel & new platforms

As always when moving to a new platform, the services will look and feel different. We are not at this point in a final stage with the design. That will get incremental updates as things move forward. We know it takes some time to get used to a new site, so please take it easy and explore the new services as they migrate over.

The reasons for going to new platforms are many.

In order to be able to provide a better experience to our users, we had to clean up some of the technical backend headaches caused by the current system. New platforms will allow us on the backend side to better support the services and stay up-to-date with new requests and platform development in order to add more functionality as we and you see fit.
The new forum platform, NodeBB, has a very active community and provides the following benefits:

  • is usable directly on mobile devices, as it supports responsive design out of the box
  • has an active open source developer community around it
  • supports plugins, and has many ready-made ones
  • plug-in creation interface is easy to use
  • has a clean modern API
  • has post tagging out-of-the-box
  • has better spam control

For the wiki, the new platform, MediaWiki provides various benefits mainly because it is also an open source solution with a large community. I will provide more information on the wiki migration in another post coming soon.


We know that getting used to a new platform and site takes a while. When you encounter something that you find annoying, and if it is a bug, please file a bugreport, but if it is an inconvenience or a feature request, please start a discussion in the Website discussion forum.

Thanks for your help and support during this migration process. All feedback welcomed!

The post Important Qt-project.org Migration to qt.io Info appeared first on Qt Blog.

Guest Post: Why I picked V-Play over Unity, Unreal & Ogre for a 2D Game

This is a guest post by Jan, an Indie game developer from Germany working on the action game FrogaBee.



This is an abstract of how I created my first tiny little game called FrogaBee. As I am just one person with a full-time-job and family duties, I do not have a lot of spare time. Because of this, I try to pick my tools wisely. I hope that this article can help others that have a good idea for a game but are in a similar situation.

Game Engine Comparison

As a programmer, I have fiddled around with several game engines in the past. I had a look at Unity, Unreal Engine and Ogre. I even wrote two game engines on my own, but I never finished them. What I have learned from writing my own game engine is, that it’s a major effort to make and keep the engine compatible and running on several platforms. So I decided to take an existing solution. All of the above mentioned solutions have got their pros and cons, but for a 2D game I decided, that V-Play would be the best solution. I have to confess, that I started using the scripting framework Qt Quick a long time ago, so I was able to start right away. But I think, that even for people that are not familiar with it, the scripting language is easy to learn and use.

I can definitely point out, what led me to be using Qt and the V-Play framework:

  • The simplicity to code (Qt Creator IDE, Qt Quick scripting language)
  • Easy scalability for phones and tablets
  • Easy deployment to mobile devices
  • Easy integration of social media
  • Shared services for a highscore list on Android and iOS
  • Almost having the game ready at the end of the two week trial phase (in the evening hours after my full-time-job)
  • Last but not least: The friendly, fast and reliable service of the V-Play team


As a Version Control System (VCS) I chose Git. It is probably not the easiest VCS, but definitely one of the most flexible and powerful ones. I think it makes sense to use some kind of VCS, no matter how small or big the project is. I have got my repository hosted at Bitbucket because it is free for up to five persons and private.

For the coding itself I used the IDE Qt Creator.

I must say, that I like the fact that V-Play is fully embedded into Qt Creator. You can even use the built-in documentation for all the custom V-Play items and you can find good explanations and examples. In my opinion, and for what I have seen so far, Qt Creator is the best integrated development environment (IDE) on Mac and the second best IDE on Windows. Even the deployment to mobile devices, no matter if it is Android or iOS, usually works just fine and fast.

Before I started to code the game itself, I looked through all the examples and demo games provided by V-Play. I took one of the demo games as a foundation for my directory- and file-layout and started to implement my own stuff. I did get along without adding any extra functionality in C++. I only used the QML and JavaScript scripting languages. QML does not really force you to write clean code. So I decided to at least separate the main game logic into a separate JavaScript file whereas the building blocks got set up in Qt Quick.


The first draft and the idea for the game were born while scribbling with my son. The game actually looks almost the same as that painting we did. When I looked at the painting the frog started to catch flies with its tongue in my mind’s eye, so a few days later I did the first digital draft of it using the software Synfig Studio and fiddled around with animations. I printed those drafts out and had them floating around at home for a while. Every now and then I wrote down an idea on that sheet of paper on how things could interact. I created the second draft of the user interface with the vector based software Inkscape. I like vector based painting for its scalability and workability. For the final rasterization and modification of all the icons I used the software Gimp.


I can definitely say that I underestimated the effort of preparing all the icons, screenshots and other graphics needed for the game itself and the online stores. Next time I will definitely spend the time to create some kind of script to resize the icons (there are twelve different sizes needed for Android and iOS). The V-Play framework recommends to provide in-game graphics in three different sizes (called sd, hd & hd2). I decided to create all the graphics for the game in the largest resolution (hd2) first. I have modified the scaling script provided by V-Play to spit out all the other needed sizes for me.


For the sound design I used free samples, some samples from my own audio library and also recorded some on my own. I just needed a simple editor to modify the samples. I used the software Audacity for it. When I implemented the game I had audio dropouts when sounds got triggered rapidly. The V-Play team thankfully helped me a lot to get rid of those issues.


In the end it was a lot of fun to create the game. I thankfully had some testers that helped me out on balancing the game to work for kids and adults. And I also have to thank the V-Play team for their supporting emails and support forum threads: one day I wrote an email to the support at 2am and received a helpful reply like ten minutes later :-) Thanks for that!

In case I wrote another game like this in the near future, I would probably be using the same tools again!


You can download Frogabee here for iOS and Android.

The post Guest Post: Why I picked V-Play over Unity, Unreal & Ogre for a 2D Game appeared first on V-Play Game Engine.

QmlBook Making Progress

It has been a long time since the last update of QmlBook was announced – but the project is definitely live and kicking. Jürgen has put in a lot of great work into the contents and gotten the collaborative work over on github started. To simplify the publication, the contents has been moved to github hosting, but you can still use the old qmlbook.org (and qmlbook.com) addresses to get there.

qmlbook-screenshotThe reason for the standstill on the qmlbook.org/com sites, and much of the perceived lack of progress is due to my personal time situation. Small children and family life takes time, as does my work (which is awesome and includes Qt/QML – go Pelagicore). Unfortunately, I’m a bit of an optimist, so I want to, and truly believe that I will have time to work on side projects such as this book. But the 24h/day limit sucks, so sometimes I realize that I fail to do so.

However, this is not a post where I complain over my own situation – instead – I want to thank all the contributors who keep feeding us issue tickets via github! I would also like to thank our readers – it is great to hear from you! And finally, I’d like to thank Jürgen who has put down a lot of work and kept the project moving forward.

It is not my intention to leave this project, I’m just short on time at the moment due to other awesome things in my life (kids, wife, work) – I’ll be back!