How Qt Signals and Slots Work - Part 3 - Queued and Inter Thread Connections

This blog is part of a series of blogs explaining the internals of signals and slots.

In this article, we will explore the mechanisms powering the Qt queued connections.

Summary from Part 1

In the first part, we saw that signals are just simple functions, whose body is generated by moc. They are just calling QMetaObject::activate, with an array of pointers to arguments on the stack. Here is the code of a signal, as generated by moc: (from part 1)

void Counter::valueChanged(int _t1)
    void *_a[] = { Q_NULLPTR, const_cast<void*>(reinterpret_cast<const void*>(&_t1)) };
    QMetaObject::activate(this, &staticMetaObject, 0, _a);

QMetaObject::activate will then look in internal data structures to find out what are the slots connected to that signal. As seen in part 1, for each slot, the following code will be executed:

// Determine if this connection should be sent immediately or
// put into the event queue
if ((c->connectionType == Qt::AutoConnection && !receiverInSameThread)
        || (c->connectionType == Qt::QueuedConnection)) {
    queued_activate(sender, signal_index, c, argv, locker);
} else if (c->connectionType == Qt::BlockingQueuedConnection) {
    /* ... Skipped ... */
/* ... DirectConnection: call the slot as seen in Part 1 */

So in this blog post we will see what exactly happens in queued_activate and other parts that were skipped for the BlockingQueuedConnection

Qt Event Loop

A QueuedConnection will post an event to the event loop to eventually be handled.

When posting an event (in QCoreApplication::postEvent), the event will be pushed in a per-thread queue (QThreadData::postEventList). The event queued is protected by a mutex, so there is no race conditions when threads push events to another thread's event queue.

Once the event has been added to the queue, and if the receiver is living in another thread, we notify the event dispatcher of that thread by calling QAbstractEventDispatcher::wakeUp. This will wake up the dispatcher if it was sleeping while waiting for more events. If the receiver is in the same thread, the event will be processed later, as the event loop iterates.

The event will be deleted right after being processed in the thread that processes it.

An event posted using a QueuedConnection is a QMetaCallEvent. When processed, that event will call the slot the same way we call them for direct connections. All the information (slot to call, parameter values, ...) are stored inside the event.

Copying the parameters

The argv coming from the signal is an array of pointers to the arguments. The problem is that these pointers point to the stack of the signal where the arguments are. Once the signal returns, they will not be valid anymore. So we'll have to copy the parameter values of the function on the heap. In order to do that, we just ask QMetaType. We have seen in the QMetaType article that QMetaType::create has the ability to copy any type knowing it's QMetaType ID and a pointer to the type.

To know the QMetaType ID of a particular parameter, we will look in the QMetaObject, which contains the name of all the types. We will then be able to look up the particular type in the QMetaType database.


We can now put it all together and read through the code of queued_activate, which is called by QMetaObject::activate to prepare a Qt::QueuedConnection slot call. The code showed here has been slightly simplified and commented:

static void queued_activate(QObject *sender, int signal,
                            QObjectPrivate::Connection *c, void **argv,
                            QMutexLocker &locker)
  const int *argumentTypes = c->argumentTypes;
  // c->argumentTypes is an array of int containing the argument types.
  // It might have been initialized in the connection statement when using the
  // new syntax, but usually it is `nullptr` until the first queued activation
  // of that connection.

  // DIRECT_CONNECTION_ONLY is a dummy int which means that there was an error
  // fetching the type ID of the arguments.

  if (!argumentTypes) {
    // Ask the QMetaObject for the parameter names, and use the QMetaType
    // system to look up type IDs
    QMetaMethod m = QMetaObjectPrivate::signal(sender->metaObject(), signal);
    argumentTypes = queuedConnectionTypes(m.parameterTypes());
    if (!argumentTypes) // Cannot queue arguments
      argumentTypes = &DIRECT_CONNECTION_ONLY;
    c->argumentTypes = argumentTypes; /* ... skipped: atomic update ... */
  if (argumentTypes == &DIRECT_CONNECTION_ONLY) // Cannot activate
  int nargs = 1; // Include the return type
  while (argumentTypes[nargs-1])
  // Copy the argumentTypes array since the event is going to take ownership
  int *types = (int *) malloc(nargs*sizeof(int));
  void **args = (void **) malloc(nargs*sizeof(void *));

  // Ignore the return value as it makes no sense in a queued connection
  types[0] = 0; // Return type
  args[0] = 0; // Return value

  if (nargs > 1) {
    for (int n = 1; n < nargs; ++n)
      types[n] = argumentTypes[n-1];

    // We must unlock the object's signal mutex while calling the copy
    // constructors of the arguments as they might re-enter and cause a deadlock
    for (int n = 1; n < nargs; ++n)
      args[n] = QMetaType::create(types[n], argv[n]);

    if (!c->receiver) {
      // We have been disconnected while the mutex was unlocked
      /* ... skipped cleanup ... */

  // Post an event
  QMetaCallEvent *ev = c->isSlotObject ?
    new QMetaCallEvent(c->slotObj, sender, signal, nargs, types, args) :
    new QMetaCallEvent(c->method_offset, c->method_relative, c->callFunction,
                       sender, signal, nargs, types, args);
  QCoreApplication::postEvent(c->receiver, ev);

Upon reception of this event, QObject::event will set the sender and call QMetaCallEvent::placeMetaCall. That later function will dispatch just the same way as QMetaObject::activate would do it for direct connections, as seen in Part 1

  case QEvent::MetaCall:
    QMetaCallEvent *mce = static_cast<QMetaCallEvent*>(e);

    QConnectionSenderSwitcher sw(this, const_cast<QObject*>(mce->sender()),



BlockingQueuedConnection is a mix between DirectConnection and QueuedConnection. Like with a DirectConnection, the arguments can stay on the stack since the stack is on the thread that is blocked. No need to copy the arguments. Like with a QueuedConnection, an event is posted to the other thread's event loop. The event also contains a pointer to a QSemaphore. The thread that delivers the event will release the semaphore right after the slot has been called. Meanwhile, the thread that called the signal will acquire the semaphore in order to wait until the event is processed.

} else if (c->connectionType == Qt::BlockingQueuedConnection) {
  locker.unlock(); // unlock the QObject's signal mutex.
  if (receiverInSameThread) {
    qWarning("Qt: Dead lock detected while activating a BlockingQueuedConnection: "
             "Sender is %s(%p), receiver is %s(%p)",
             sender->metaObject()->className(), sender,
             receiver->metaObject()->className(), receiver);
  QSemaphore semaphore;
  QMetaCallEvent *ev = c->isSlotObject ?
    new QMetaCallEvent(c->slotObj, sender, signal_index, 0, 0, argv, &semaphore) :
    new QMetaCallEvent(c->method_offset, c->method_relative, c->callFunction,
                       sender, signal_index, 0, 0, argv , &semaphore);
  QCoreApplication::postEvent(receiver, ev);

It is the destructor of QMetaCallEvent which will release the semaphore. This is good because the event will be deleted right after it is delivered (i.e. the slot has been called) but also when the event is not delivered (e.g. because the receiving object was deleted).

A BlockingQueuedConnection can be useful to do thread communication when you want to invoke a function in another thread and wait for the answer before it is finished. However, it must be done with care.

The dangers of BlockingQueuedConnection

You must be careful in order to avoid deadlocks.

Obviously, if you connect two objects using BlockingQueuedConnection living on the same thread, you will deadlock immediately. You are sending an event to the sender's own thread and then are locking the thread waiting for the event to be processed. Since the thread is blocked, the event will never be processed and the thread will be blocked forever. Qt detects this at run time and prints a warning, but does not attempt to fix the problem for you. It has been suggested that Qt could then just do a normal DirectConnection if both objects are in the same thread. But we choose not to because BlockingQueuedConnection is something that can only be used if you know what you are doing: You must know from which thread to what other thread the event will be sent.

The real danger is that you must keep your design such that if in your application, you do a BlockingQueuedConnection from thread A to thread B, thread B must never wait for thread A, or you will have a deadlock again.

When emitting the signal or calling QMetaObject::invokeMethod(), you must not have any mutex locked that thread B might also try locking.

A problem will typically appear when you need to terminate a thread using a BlockingQueuedConnection, for example in this pseudo code:

void MyOperation::stop()
    m_thread->wait(); // Waits for the callee thread, might deadlock

// Connected via a BlockingQueuedConnection
Stuff MyOperation::slotGetSomeData(const Key &k)
    return m_data->get(k);

You cannot just call wait here because the child thread might have already emitted, or is about to emit the signal that will wait for the parent thread, which won't go back to its event loop. All the thread cleanup information transfer must only happen with events posted between threads, without using wait(). A better way to do it would be:

void MyOperation::stop()
    connect(m_thread, &QThread::finished, this, &MyOperation::cleanup);
    /* (note that we connected before calling quit to avoid a race) */

The downside is that MyOperation::cleanup() is now called asynchronously, which may complicate the design.


This article should conclude the series. I hope these articles have demystified signals and slots, and that knowing a bit how this works under the hood will help you make better use of them in your applications.

Release 2.7.0: New App Components, Qt Maps Demo & Project Templates

The latest V-Play release, 2.7.0, adds many new features to V-Play Apps! Besides making a number of general improvements to the app SDK, a new Qt Creator project wizard and improved Qt map support (with Mapbox and OpenStreetMap as map providers) have been included.

There’s also a number of styling improvements with the addition of new icon buttons, page controls and native dialogs.

You can get V-Play 2.7.0 here or else update your current V-Play installation using these instructions.

Update Now!

Create Map-Based Apps with V-Play 2.7.0

Enhanced map support for V-Play Apps is one of the best features of V-Play 2.7.0. With the new AppMap component, you can create apps with built-in Qt map functionality that show a user’s location anywhere in the world. An open source demo that uses the AppMap component can be seen here.

The AppMap component works with map app provider plugins such as OpenStreetMaps and Mapbox.

V-Play 2.7.0 - Map Example

The New Project Wizard

When creating a new project with V-Play, users will now have a selection of app templates to begin their projects with. You can now start off your development process with a master-detail template, a tabbed application template or a maps application template.

These templates will speed up the development process for anyone that wants to make a cross-platform app. Just open Qt Creator from your V-Play installation directory, select “New Project” from the welcome screen and then select “V-Play Apps” from the Projects pane on the left to see these new templates.

V-Play 2.7.0 - Projects Wizard

Styling Improvements

V-Play 2.7.0 includes a number of advanced styling options to improve the UI of your app. This update includes a new IconButton component that can be used with to implement over 600 different icons as buttons in your mobile app. These buttons can then be used as push buttons or toggle buttons with multiple states.


The new PageControl component displays a row of dots, each of which correspond to a custom page or other block. The currently viewed page is indicated by a filled dot. You can also customize this component with different icons instead of dots to give your app a unique feel.

V-Play 2.7.0 - pagecontrol-search

It’s also now possible with the NativeDialog component to show platform-native dialogs as an alternative to custom-styled dialogs with the InputDialog component.

V-Play Apps Improvements

The latest version of V-Play also includes a large range of upgrades to existing V-Play Apps components that will allow users to enjoy native feel and experience in your apps.  You can see a full list of the benefits of V-Play 2.7.0 here, but the main improvements are:

  • AppSwitch: Adds an individual backgroundColor property and adds more styling options from within a global Theme.
  • AppTextField: The cursor color matches Theme::tintColor by default but can be overridden as an individual cursorColor property or globally with Theme::inputCursorColor property. The new clearsOnBeginEditing property allows clearing out existing content as soon as the input control gains focus (as an example, this is a common pattern for password input fields). The new property showClearButton displays a button to quickly clear out entered content by the user, without the need of using the backspace key.

V-Play 2.7.0 - ClearText

  • PictureViewer: When opened, the status bar is hidden automatically.

PictureViewer provides two new signal handlers opened and closed and the new property isOpen to handle state changes when opening or closing the picture viewer.

  • NavigationBarRow: A new feature (property showMoreButton) enables you to auto-collapse items in a more menu as familiar from the Android platform. This also includes new properties title and showItem for NavigationBarItem to customize the appearance of individual items within a NavigationBarRow.
  • TabControl: It’s now possible to hide the icons from the tab bar when setting the showIcon to false. This is especially useful (and the default value) on Android where tabs appear as text-only items.

V-Play 2.7.0 - TabControl


Get Map-Based App Demo and see Styling Improvements on your Mobile Device!

To test the new map-based app demo and styling improvements on your PC, just run the updated V-Play Sample Launcher.

To test the new features on your mobile device, download the V-Play Showcase App for Android or iOS:
Google_Play_Badge (1) iTunes_download_link

How to Update

Test out these new features by following these steps:
Step 1

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

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

Step 2

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

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

V-Play Sample Launcher

Now just select the Demo Apps link on the left or one of the game demos, and you can explore & copy the source code of the demos right from the Sample Launcher!

Hint: There was also a major addition in the game engine parts! We’ll officially announce it next week, but you can have a look at the changes already in the changelog.

The post Release 2.7.0: New App Components, Qt Maps Demo & Project Templates appeared first on V-Play Game Engine.

Upcoming maintenance break on the Qt Forums Monday 8.2.2016


We will have a maintenance break on the Qt Forums early Monday morning 8.2.2016, starting around 7.00 CET.

The target of the break is to do a major version update and do some cleaning of the database at the same time.

The break will last an estimated three hours, so we should be back online at aroung 10.00 CET. We’ll be updating the status on twitter as we get things done.

Sorry for the inconvenience.

The post Upcoming maintenance break on the Qt Forums Monday 8.2.2016 appeared first on Qt Blog.

Compilers and error messages

So. I typo’ed up some template code the other day. And once again I learned the importance of using several c++ compilers.

Here is a very reduced version of my code:

#include <utility>
template <typename T> auto foo(const T& t) -> decltype(x.first)
return t.first;
int main()
return 0;

And let’s start with the compiler I was testing with first.

MSVC (2013 and 2015)

main.cpp(8): error C2672: ‘foo’: no matching overloaded function found
main.cpp(8): error C2893: Failed to specialize function template ‘unknown-type foo(const T &)’

It is not completely clear from that error message what’s going on, so let’s try some other compilers:

GCC (4.9-5.3)

2 : error: ‘x’ was not declared in this scope
template <typename T> auto foo(const T& t) -> decltype(x.first)

That’s pretty clear. More compilers:

Clang (3.3-3.7)

2 : error: use of undeclared identifier ‘x’
template <typename T> auto foo(const T& t) -> decltype(x.first)

ICC (13)

example.cpp(2): error: identifier “x” is undefined
template <typename T> auto foo(const T& t) -> decltype(x.first)

(Yes. I mistyped the variable name used for decltype. Replacing the x with t makes it build).

Thanks to and for testing with various compilers.

Qt and Direct3D 12 – First Encounter

The landscape of graphics APIs is changing. Qt Quick 2, released with Qt 5.0 in 2012, was betting heavily on OpenGL and OpenGL ES 2.0. There have been changes and improvements since then – the Qt Quick 2D Renderer was introduced, experiments with software rasterizers were made, and enablers for newer OpenGL versions got added all over the Qt graphics stack. However, as Lars mentioned in his Qt World Summit 2015 keynote, the situation is changing: new, low-level, more efficient APIs like Vulkan, Metal and Direct3D 12 are about to become widely available. Some of these are tied to certain platforms, making them the best choice when targeting the platform in question, while others are expected to be present on a wider variety of systems. At the same time betting solely on a complex, accelerated API is not always the best choice: traditional, desktop user interfaces running on older hardware are sometimes better served with plain old CPU-based rendering.

Therefore, unsurprisingly enough, one of the research areas for upcoming Qt versions is making the graphics stack, and in particular, Qt Quick, more flexible, with support for different graphics APIs as well as software rendering.

Such research work often leads to useful side effects: this post is about one of these, a simple Qt module enabling easy integration of Direct3D 12 rendering into a standalone Qt window – or alternatively QWidget-based applications – and making it easier to get started and experiment with modern D3D techniques while continuing to enjoy the familiar APIs, tools, and development environment Qt and its ecosystem offer.

What it is

The QtD3D12Window module, living in a qt-labs repository, is a Qt 5.6 module providing a QD3D12Window class similar to QOpenGLWindow, a handy qmake rule for offline HLSL shader compilation via fxc, and a comprehensive set of examples for a number of basic use cases (inspired by Microsoft’s own Hello World samples).

What it is not

Before going further, let’s reiterate what this module is not: it is not a way to run existing Qt applications on Direct3D (that is exactly what ANGLE provides when it comes to D3D9 and 11), nor does it support Qt Quick in any way. It is also not something that will get added to Qt in its current form, and it is not a complete engine or framework of any kind (the interface QD3D12Window offers is likely insufficient for more complex, multi-threaded approaches).


The first step for integrating custom rendering code using a new graphics API is to make the rendering target a QWindow’s underlying native window. Currently OpenGL is the only choice and it is deeply integrated into Qt both internally (QPA interfaces, platform plugins) and externally (public APIs, see the QOpenGL classes in QtGui for instance). This is expected to change in the future, but for now, for our standalone D3D experiment, we will just do everything on our own. Qt’s windows platform plugin makes it easy to obtain the native window handle (HWND) as that is exactly what QWindow::winId() returns in Qt applications running on Windows. We can then use DXGI to enumerate the available adapters, pick either a hardware one or WARP, and create a swap chain. QD3D12Window handles all this, with defaults that are good enough for the typical basic applications.

Speaking of DXGI, this marks our first foray into graphics adapter and device management: while with OpenGL and its usual windowing system interfaces such capabilities are limited, other APIs (especially the ones tied to platforms with a suitable driver model) may offer a lot more when it comes to discovering graphics adapters and managing device changes, removals and resets during the lifetime of the application. Such functionality, on platforms and APIs where available, is expected to get more focus in Qt in the future.

While implementing QD3D12Window, it turned out there was no need to do much generic plumbing – thanks to the way QOpenGLWindow and QRasterWindow had been introduced back in Qt 5.4: the common base class QPaintDeviceWindow (somewhat misleading in the D3D case as our window here is not suitable for QPainter-based painting) provides all the necessary infrastructure so subclasses can focus on the graphics API specifics while getting the basic, consistent Qt functionality – like update() – out of the box. This is good news since it allows easy experimenting with other APIs as well in the future (QMetalWindow, QVulkanWindow, you name it).


QD3D12Window mirrors QOpenGLWindow which in turn is based on QOpenGLWidget/QGLWidget’s well-known initializeGL – resizeGL – paintGL interface, with GL becoming D3D, naturally. There are two new functions subclasses may reimplement: releaseD3D and afterPresent. The latter is invoked every time after issuing a Present call: most simple applications will wait for the GPU via a fence here. The former is used to make applications able to survive device removals: when the graphics device becomes unavailable, this function is invoked and is expected to release all resources it has created during initialize/resize/paint. QD3D12Window will then then take care of starting over and invoking initializeD3D again. This way the application can remain functional even when a driver update or a timeout in shader execution occurs.

The best is probably to dive straight into the examples, looking at hellotriangle for instance shows that if you haved used QOpenGLWindow or QOpenGLWidget before, QD3D12Window will present no unexpected surprises either.


So now we can have a top-level window with nothing but our awesome D3D12-rendered content in it. This is excellent but what about having some traditional user interface controls in there? For now, the approach that is usable with QD3D12Window is to make it a native child window via QWidget::createWindowContainer(). This comes with the usual limitations so be sure to read the documentation first. Nonetheless it will work fine for most simple purposes.


hellooffscreen, one of the QD3D12Window examples


The handling of shader code and compilation is another very interesting topic. With OpenGL, Qt and Qt Quick bet on runtime compilation due to that being the only universally available solution not involving vendor and platform specifics. With other graphics APIs in the future, it is expected that Qt will focus more on offline compilation, integrating it into the build system as much as possible. Besides the obvious performance benefits, this drastically improves the development workflow as well: getting a proper compiler error right when hitting Ctrl+B in Qt Creator can easily feel infinitely superior to the “old” way of browsing the debug output while running the application.

The QtD3D12Window module comes with a simple qmake rule that allows invoking fxc.exe during build time. All the examples use this to generate header files where the compiled bytecode is provided as a plain char array. Take a look at the the .pro file for one of them and the shader setup for the pipeline state. Simple and easy, isn’t it?

All this is not completely new to Qt: the bundled ANGLE in qtbase performs shader compilation in the same manner. However, that is hidden to and not usable by application-level D3D code, while the hlsl.prf file here can be copied over to the Qt SDK’s mkspecs/features folder, making it available to any Qt application.

Graphics Debugging

QD3D12Window automatically enables the D3D12 debug layer. This is extremely useful in practice as many of the common mistakes made while getting started with D3D12 result in human readable, verbose and actually helpful debug messages. However, you may want to disable this when doing performance testing or overhead comparison.

Another helpful tool is the graphics debugger included in Visual Studio. One way to launch this for Qt apps is doing devenv /debugexe qtapplication.exe from a developer command prompt and hitting Alt+F5. (alternatively, generating Visual Studio project files with qmake -tp vc may work too) This proved to be quite useful while developing even our simple examples – for instance the ability to inspect graphics resources and see if we managed to correctly generate all mipmap levels is immensely helpful.


As mentioned before, the module comes with a set of examples that cover the basics and may be useful to anyone getting started with D3D12 development. See the readme for an overview.

That’s it for now, hope you find our little labs module useful. Happy hacking!

The post Qt and Direct3D 12 – First Encounter appeared first on Qt Blog.

Using Qt 3D to visualize music

As the development of the Qt 3D module is proceeding we wanted to give it a try and test how one could visualize music using the module. The result of this experiment was a new example, Audio Visualizer Example, to the Qt 3D module.


Audio Visualizer Example playing Lost Neon Sun by Tiltshifted

The example shows how you can use Qt 3D rendering with Qt Quick elements. The 3D content is rendered using the Scene3D type. The bars are objects in NodeInstantiator and they are animated to visualize the magnitude of the music played. On top of the scene we’ve placed buttons to pause/play and to stop the music. These buttons are Qt Quick elements. The music is played using MediaPlayer provided with Qt Multimedia module.

In the example there’s a curve shaped 3D entity to show the progress based on the duration of the played track. There’s also a prism 3D entity to show the title of the example and the song. The prism shows the title of the song while the song is played and the title of the example becomes visible when the playing is stopped. The titles are placed on different edges of the prism and the angle of the prism is animated once the title needs to be changed.

If you want to give the example a try you can find it from under examples\qt3d\audio-visualizer-qml. We are aware that there are still some improvements that could be made to the backend performance to make the animation of the bars smoother, but as Qt 3D is Technology Preview in the upcoming Qt 5.6 release these improvements are more than likely.

This example was created to give some ideas of what you can achieve using Qt 3D. We hope you like it!

The post Using Qt 3D to visualize music appeared first on Qt Blog.

Iori Ayane – Qt Champion


We start the introduction of the 2015 Qt Champions with Iori Ayane who is an active participant in the Japanese Qt scene.

Qt is big in Japan, Iori is the second Japanese Qt Champion in two years. There is a really impressive community of Qt users in Japan with regular meetups and activities.

Iori first saw Qt at a workshop in Nagoya in 2011 held by Suzuki-san (Qt Champion 2014).

The thing that really resonated for Iori was Qt Quick, which he immediately started using after the workshop and hasn’t stopped since.

Among the projects he has made are:

  • a Twitter client, that he used as an introduction project for himself. It started off as a Windows Mobile project, but worked on multiple platforms including all desktop platforms, Android and Meego (Nokia N9)
  • A space invaders style space shooter, that was coded in under a week. (The graphics are fan art for Madoka ☆ Magica, a Japanese anime)
  • An Android custom theme viewer application, used for viewing Android custom themes on the PC while you create them. It works with a Japanese custom Android ROM.
  • A tool with which you can play web games and easily share screenshots from them to twitter. It’s a web browser with tools specifically to take screenshots and share them.

While Iori has coded a lot, the thing that sets him really apart is that he has written several books on Qt in Japanese. This also started much like his coding with Qt Quick. After coding with Qt Quick for a while Iori felt that Qt Quick is such a wonderful technology that it should be more widely known. However there were no books in Japanese at the time. Iori had written about Qt Quick on his blog, but it felt limited, so he wrote an introduction to Qt Quick in Japanese and got it published with the help of friends.


Iori presenting Lars Knoll with his books at Qt Contributors’ Summit 2015.

On top of all that Iori has also been translating the Qt Installer Framework to Japanese and last year he started committing patches to Qt based on his translation. As a side project from the Qt Installer Framework work, Iori has written a book on the Framework and it has also been published.

The thing that has really impressed Iori in the Qt Community is that everyone is accepted as part of the community. The Japanese Qt community has grown as more people know about Qt and they have regular meetups and workshops in several locations.

Iori himself started with just making small hobby programs and has now made several books and patches to Qt. He likes to tell people about Qt and how easy it is to get started with Qt.

Again, congratulations to Iori on the title of Qt Champion 2015!

The post Iori Ayane – Qt Champion appeared first on Qt Blog.

High-DPI Support in Qt 5.6

by Morten Johan Sørvig (Qt Blog)

Qt 5.6 brings improved high-DPI support, in the form of better support for the devicePixelRatio scaling mode. In this blog we’ll look at how to configure and enable it, from the perspective of a Qt application user and a Qt application developer.

unscaled sammegame vs scaled samegame

Unscaled sammegame vs scaled samegame

Developing applications won’t be covered in depth now, but has to some extent been covered earlier. The short story is that applications generally benefit from this high-DPI mode even without modifications.

This high-DPI mode is a virtualization mode, where there is not necessarily a 1:1 correspondence between a unit in the QWidget/Quick item coordinate system and a pixel on screen. One “unit” then has constant visual size across systems with different display densities, and actual screen pixel density is to a large degree hidden from the application.

Dots Per Inch (DPI) is the traditional measurement for display density, where a standard density display has a DPI value of 72 or 96. Qt as always scaled fonts automatically according to the system DPI, and then the application code was responsible for scaling hardcoded layout sizes. The Qt styles would to a certain degree adapt to the font size. The devicePixelRatio mode is different in two ways: First, the display density is expressed as a scale factor — the devicePixelRatio in Qt — ranging from 1 to n. Second, the scale factor is applied lower in the stack (on the Apple platforms at the OS level), and is less directly used in application code.

There is often a fixed relation between DPI and scale factors on a given platform:

Android DPI and scale factors
class DPI Scale Factor
ldpi 120 0.7
mdpi 160 1
hdpi 240 1.5
xhdpi 320 2.0
xxhdpi 480 3.0
xxxhdpi 640 4.0

From stackoverflow. Quiz: Why is 1x 160 DPI on Android, compared to ~90 on desktop?

Demonstrating rendering at display densities on a blog is difficult. What we can do instead change the devicePixelRatio Qt sees while keeping the display scale factor constant. This results in larger visual sizes at higher devicePixelRatios:


The Qt Labs Controls SpinBox at various scale factors, including the unsupported 1.5x.

Enabling high-DPI support: Qt needs to be provided with a scale factor for all displays on the system. There are several possible sources for the scale factors: The values can be provided directly by the OS, Qt can compute them based on traditional display metrics provided by the operating system (such as the DPI value), or the user or developer can provide them directly. The mechanisms for setting and enabling the sources are environment variables and application attributes.

Historical Sidebar:Qt 5.4 and Qt 5.5 on X11 and Windows supports setting the devicePixelRatio with QT_DEVICE_PIXEL_RATIO=n (integer only). This setter has now been deprecated and replaced with several others, as described below.

Let’s look at three different cases:

Case I: The operating implements high-DPI scaling and provides a scale factor.

This is the situation for the Apple platforms – the OS enables the high-dpi mode, and Qt and the application come along for the ride.

This is also the case for Qt on Wayland when the Wayland display server is configured with scaling enabled:

./weston --scale 2

For the experimentally inclined, Qt for Native Client also gets a scale factor set when browser zoom is activated.

Case II: Qt supports the scaling and computes a scale factor.

Supported platforms: X11, Windows, Android, Eglfs

Qt can enable devicePixelRatio scaling on platforms that do not support it natively. This can be done via an environment variable or an application attribute in the application source code:


Qt will then query the the operating system for display metrics using native API, or in the eglfs case fall back on QT_QPA_EGLFS_PHYSICAL_WIDTH, QT_QPA_EGLFS_PHYSICAL_HEIGHT and the display pixel size.

Enabling can also be vetoed, either by environment variable or by the application:


The use-cases for vetoing are “I’m not getting correct DPI values from my displays” and “my application really needs to work in display pixels”. Note that this vetoing only disables “Case II” scaling: Qt can of course not change how the OS works, and manual set scale factors (below) are also kept as as a separate case.

Case III: Setting a scale factor manually.
Supported Cross-platform.


Sets the scale factors for all screens. Screen order is QApplication::screens() order. This setter assumes that text has already been properly scaled for the display, through the DPI setting, and then scales the rest of the user interface to match.


Sets a global scale factor for the entire application, scaling everything uniformly. This final option is useful for development and testing, and allows you to test any scale factor on any hardware. It can also be useful for some embedded scenarios – for example if you are targeting a single display type with a full-screen application: tweak the scale factor until the UI has the correct visual size.

The finer points:

Q: What happens if I use more than one of these setters?
A: The scale factors are multiplicative. Setting QT_SCALE_FACTOR=2 on a 2x device gives an effective devicePixelRatio of 4.

Q: Are non-integer scale factors supported?
A: Qt uses qreal in the API, and will allow setting non-integer scale factors via QT_SCALE_FACTOR. However, Qt does not guarantee that graphics and styles will be glitch-free in that case. Styles may break first: the fusion style is generally most scalable. The Qt platform plugins round the reported scale factors to the nearest integer.

Q: Could a scale factor of 0.5 allow me to work in device pixels on a 2x device?
A: That’s uncharted waters, but a possibility.

The new High-DPI functionality is part of Qt 5.6 release. To try it out, please check out the Qt 5.6 Beta.

The post High-DPI Support in Qt 5.6 appeared first on Qt Blog.

Creating a Qt 5 port to Apple tvOS

Back in November, Apple released the latest generation of it’s Apple TV product. Besides the slightly improved hardware, the true new feature is the OS which is now officially based on iOS and comes with the dedicated SDK and App Store! So we started investigating what it would take to port Qt to tvOS and start writing some apps for the big screen.

Turns out, it’s pretty straight forward (see other change list for the various modules). The port involves a new mkspec, setting some build flags, disabling a few things tvOS does not do compared to iOS. Et voilà, a working environment to port your QML app, yoohoo! That you can’t interact with, boohoo!

Read on to see the current progress and check what remains to be done.

The Platform

From a technical point of view, tvOS 9.0, feature wise, is on par with iOS 9. But it differs in a number of ways:

  • It requires bitcode compilation – this is simple compile time flag and will be a requirement for a future version of iOS (10?). Bitcode is an intermediate representation of the binary which enables Apple and iTunes Connect to perform optimisations on your application without need for recompilation or even uploading a new build (for example when a new processor is launched).
  • Platform is 64bits only, based on Apple’s A8 chip (as in the iPhone 6, previous generation), so dual core CPU and quad core GPU with OpenGL ES 3. It does have 2Gigs RAM though, we have noticed apps don’t get killed in the background as much.
  • A lot of underlying POSIX commands and or system calls that don’t make sense on the platform are actually disabled in the API, like spawning processes, etc.
  • It has no support screen orientation, status bar settings, clipboard, (a la iOS) menus, cameras, sensors and neither Webkit nor WebEngine (nor Webview!).
  • User interaction is very different, using the provided remote. So no direct touch, presses and touch events are sent to the focus view, and the keyboard is always full screen with a dedicated input UI.
  • Beyond the things disabled in the existing iOS build, we’ve disabled DBus (can’t use it anyway) and Widgets (why would you use those for a 10′ interface?).
  • Supports shared library builds for device target only (not simulator or mixed targets).

The Port

To start the port, we duplicated the iOS mkspec and tweak the build options to target the tvOS device and simulator SDKs, add the required compile flags, etc.


Every platform supported by Qt must provide an mkspec which is composed of a collection of files containing build instructions (such as which modules are supported), what the compiler and linker options are, and many more things.

Importantly in the case of iOS and tvOS, it will instruct qmake to cross-compile for the correct architectures, to build for both the device and simulators, etc.

A tvos config was added to qmake, along with the pre-existing Q_OS_TVOS compile time macro. These are not linked to their iOS counter parts, so ios does not imply tvos or the other way around.

After the initial setup, it became apparent that the differences between iOS and tvOS where quite minimal, mostly related to the choice of the SDKs, the target devices, and so on. So the iOS mkspec (and dependent files) where refactored to minimise the amount of duplication.

Beyond setting up the mkspec, we also needed to make sure the parts of build system and code that had options specific to iOS (using the ios config in qmake or the Q_OS_IOS define in code) where also handled properly for tvOS. This was done in all modules currently available.

Building Qt and your Apps

To build Qt (or your own apps), you will need Xcode 7.2 which includes tvOS 9.1. There’s no reason if should not work with the previous release but it has not been tested.

Many of the iOS specific entries in the Info.plist file are also different on tvOS so a new template was added. tvOS also requires asset catalogs for the app icons.

Building Qt itself requires passing the -xplatform macx-tvos-clang option to the configuration script. 

As with the iOS builds, the tvOS port currently builds static libraries by default. We have confirmed that building shared frameworks is possible but, in that case, only the appletvos SDK will be built. The option is however not publicly available (pending further testing).

Creator does not currently support tvOS builds properly so building your own apps will require invoking qmake on the command line and opening the generated project in Xcode (gasp!).

Finally, tvOS has pretty strict rules on the size of the final application bundle. This appears to be enforced at the launcher level (rather than at the App Store submission level) which means debug builds are too large and will not run on the device (they work fine in the simulator).

So, build Qt for tvOS, then build your favourite app, run it on your big screen. Tada!

User interactions

Then you try to interact with your app and nothing works. Main issue is that the interaction paradigm for a large screen you’re too far away to touch is completely different from using a phone or even a desktop computer. There’s no direct touch on any UI component, nor is there any concept of a mouse pointer to be moved around.

Now, the Apple TV comes with a remote that does have a touch surface. And that does report touch events and gestures. But, when using tvOS’s native SDK, these are dispatched to the view that currently has the focus. However all the coordinates for the touch gestures always start in the centre of the screen and move from there (i.e. they are not reported in the coordinate system of the button or whatever element has the focus).

So in most QML apps, since there is a single native view, all events are reported to the event dispatch system as happening in the centre of the screen.

The native SDK also has a system to gracefully handle the change in focus based on the layout of the focusable views, so that swiping left, right, up or down will move the focus to the next view in a predictable (and developer controllable) way.

All this is to say that something needs to be done so that QML can provide a similar framework for graceful event dispatching and focus handling.

Meanwhile, you’d have to add a top level fullscreen MouseArea handle clicks, gestures, active items, etc. on your own.

Qt3D and games

Qt3D on AppleTV

An area where interaction may be simpler is gaming and using controllers. Apple provides an SDK for the Made-For-iOS type controllers and the remote bundled with the Apple TV is actually supported as such a controller, including tilt sensors, etc.

Using Qt3D and the upcoming input-device framework, it is possible to use such gaming controllers for game-type applications.

We are also making sure the qtgamepad project in qt-labs also support tvOS and it’s remote.

Further work

Well, obvious things: reviews to the current ground work so it can be merged. Then sorting out the interactions issue in a nice manner. And getting Creator to properly configure and deploy the apps.

Also simple message boxes need to be added, and text input (something like a QML version of QInputDialog would be nice).

Hoping to get more people involved for this :)

The post Creating a Qt 5 port to Apple tvOS appeared first on KDAB.

How to integrate OpenGL code with Qt Quick 2 applications (part 2)

In the last blog post we gave a very high level introduction to the Qt Quick 2 renderer. We also showed how various signals are emitted by the renderer during the synchronization and rendering steps. In this blog post we’re going to discuss those signals and show how they can be used to implement overlays and underlays.

Signals emitted by the Qt Quick renderer

Let’s start again by looking at this diagram of the synchronization between the render thread of the renderer and the main thread when a new frame needs to be rendered:


What are exactly the signals emitted by the Qt Quick 2 renderer that we can use? Some of them are visible in the picture above, some of them are not, so I will list all of them here:

  • QQuickWindow::sceneGraphInitialized: emitted when the renderer initializes the OpenGL context and the scene graph resources.
  • QQuickWindow::sceneGraphInvalidated: emitted when the renderer has invalidated the scene graph, and the OpenGL resources should be freed.
  • QQuickWindow::beforeSynchronizing: emitted before the scene graph synchronizes with the main thread. However, the main thread is already blocked at this point.
  • QQuickWindow::afterSynchronizing: emitted after the scene graph synchronized with the main thread. The main thread is still blocked at this point.
  • QQuickWindow::beforeRendering: emitted before any rendering by the Qt Quick renderer has taken place.
  • QQuickWindow::afterRendering: emitted after the Qt Quick renderer has rendered the scene graph.
  • QQuickWindow::frameSwapped: emitted after the Qt Quick renderer has swapped the back and the front buffers.

That is a lot of signals indeed! But it’s extremely good news, because it means we can intervene at any point of the synchronization/render process by simply connecting slots to these signals. An important consideration is that the OpenGL context used by the Qt Quick renderer will be bound when the signals are emitted. This means we can simply have OpenGL calls in our slots, without the problem of finding the “right” OpenGL context to use and make it current.

Also, note that the signals are emitted from the render thread, not the main thread. This typically means that we will need to force the connection type to Qt::DirectConnection, if the receiver object lives in the main thread. It also means we will need to carefully manage shared state between the main thread and the GUI thread, for instance by protecting the state with mutexes.

Remember that after the synchronization is complete, the main thread is unblocked and free to go while the rendering signals are being emitted; we can easily have races between the main thread and slots invoked directly from the render thread.

OpenGL underlays and overlays

So how can we implement, for instance, a simple underlay (that is, drawing custom OpenGL content below a scene)? Here’s a screenshot of an example application:


The trefoil knot is rendered by an external piece of OpenGL code that we are not going to discuss here. Let’s assume is some existing code we don’t want to touch, and treat it as a black box. The small controls on the bottom are instead implemented using Qt Quick. As you can see, the controls are truly over the OpenGL content, and nicely blended with it.

The three sliders control the position of the virtual camera in the world (in spherical coordinates). For simplicity, these coordinates are wrapped by a Camera class, an instance of which gets exposed to the QML engine.

How can we obtain this result using the signals emitted by Qt Quick? Here you are the relevant parts of a possible implementation, done using a subclass of QQuickView.

Let’s start by looking at the constructor:

QuickView::QuickView(QWindow *parent)
    : QQuickView(parent)
    , m_camera(new Camera(this))
    , m_renderer(new MeshRenderer(this))
    connect(this, &QQuickWindow::sceneGraphInitialized,
            this, &QuickView::initializeUnderlay,

    connect(this, &QQuickWindow::beforeSynchronizing,
            this, &QuickView::synchronizeUnderlay,

    connect(this, &QQuickWindow::beforeRendering,
            this, &QuickView::renderUnderlay,

    connect(this, &QQuickWindow::sceneGraphInvalidated,
            this, &QuickView::invalidateUnderlay,

    connect(m_camera, &Camera::azimuthChanged, this, &QQuickWindow::update);
    connect(m_camera, &Camera::elevationChanged, this, &QQuickWindow::update);
    connect(m_camera, &Camera::distanceChanged, this, &QQuickWindow::update);


    rootContext()->setContextProperty("_camera", m_camera);

In the constructor a Camera object gets created, representing the position of our virtual camera, and a MeshRenderer object, which is our black box performing OpenGL rendering (drawing the knot).

We then connect some of the signals emitted by the Qt Quick renderer to some local slots. We’re not interested in all of them; for this example just want to know:

  • when the scene graph is getting created and destroyed, so we can initialize and release the OpenGL resources;
  • when the synchronization round is happening, so we can safely access state in the main thread (which is blocked);
  • when Qt Quick is about to start rendering the next frame, so we can paint before it, therefore realizing an underlay.

Notice the Qt::DirectConnection connection type. Since the receiver (this) is living in the main thread, and the signal is emitted by the render thread, we must force the connection type otherwise it would result in a queued invocation, with disastrous results.

After those connections, we connect the update slot to the various changed signals from the Camera object, because every time the camera moves we want to schedule a redraw.

We then ask Qt Quick not to issue a glClear on the color buffer before starting its own rendering. Since we want to draw something before Qt Quick, clearing would result in not seeing anything of what we had rendered. The setClearBeforeRendering call disables (or enables) the automatic clearing.

Finally, we expose the Camera object to QML (so that it can be manipulated through the Qt Quick sliders) and load a QML file.

What about the slots themselves? Let’s have a look:

void QuickView::initializeUnderlay()

void QuickView::invalidateUnderlay()

void QuickView::renderUnderlay()

void QuickView::synchronizeUnderlay()

Yes, it’s that simple! Since our renderer is a black box, we simply call into it from the slots.

When the scene graph is initialized or invalidated, we respectively initialize or invalidate our renderer.

When Qt Quick is about to render itself, we call our own rendering code, resulting in drawing below Qt Quick.

A bit more interesting is the synchronization slot. Remember that all these slots are called directly from the render thread; as such, concurrent access from the main thread could easily result in a data race. While we could expose the Camera object to our custom OpenGL code, we would then need to implement a thread-safe Camera, which may be tricky or just impossible.

For this reason, we’ve decided to follow what the Qt Quick renderer does: we extract from the objects living in the main thread all the information required for rendering the frame. In this case, the object living in the main thread is m_camera, and the information are the spherical coordinates, which get stored somewhere else (for instance inside our black box renderer). All of this happens during the synchronization stage, while the main thread is blocked, so there is no risk of concurrent access and therefore data races.

Finally, what is the deal with all the resetOpenGLState calls? The fact is that the Qt Quick renderer does not like modifications to the OpenGL state. In other words, if in our slots we modify some OpenGL state (bind textures, change the used shader program, and so on), we must reset the OpenGL state to whatever it was before we touched it.

While this is possible in theory (OpenGL has all the necessary APIs for querying state), it’s also terribly complicated due to the countless settings that OpenGL has; moreover, if we simply call into some third party code, we have no control over which state gets touched by that. For this reason, there is a convenience call that resets the OpenGL state: QQuickWindow::resetOpenGLState. Be sure to call this function every time some OpenGL state gets modified in a slot!

That’s it!

Further steps

In the next blog post we are going to deeply integrate a custom OpenGL item inside a Qt Quick 2 scene. Stay tuned!

About KDAB

KDAB is a consulting company dedicated to Qt and offering a wide variety of services and providing training courses in:

KDAB believes that it is critical for our business to invest into Qt3D and Qt, in general, to keep pushing the technology forward and to ensure it remains competitive.

The post How to integrate OpenGL code with Qt Quick 2 applications (part 2) appeared first on KDAB.

Notification for all Qt Cloud Services users

Over a year ago we launched Qt Cloud Services, which includes Managed Runtime Services, Managed Application Runtime (MAR), Managed Database (MDB) and Since then we have received great feedback and seen some amazing cloud-connected applications published on the platform. However, the take-up of our services has not been what we had hoped. Consequently, we are currently looking into ramping down Qt Cloud Services. Meantime we will be discontinuing further sales.

We value our customer relationships and therefore believe in providing you as much transparency on this as early as possible. The service will be up and running at least through H1 2016. You will receive at the minimum 3 months’ notice prior to any changes.

Again, we value your business and welcome you to contact us to discuss your particular concerns and questions via


Best regards,

The Qt Cloud Services Team

The post Notification for all Qt Cloud Services users appeared first on Qt Blog.

Eight Golden Rules: Rule 1 - Strive for Consistency

In Ben Shneiderman's Eight Golden Rules of Interface Design, he wrote: "Consistent sequences of actions should be required in similar situations; identical terminology should be used in prompts, menus, and help screens; and consistent color, layout, capitalization, fonts, and so on should be employed throughout. Exceptions, such as required confirmation of the delete command or no echoing of passwords, should be comprehensible and limited in number."

QNanoPainter - a brief update

QNanoPainter has been now publicly available for about a month and during this time has seen some nice improvements.

Gunnar first added Windows support, then worked on reducing QNanoQuickItemPainter creation time and memory consumption with multiple items. Niels and Jean-Michaël did some performance testing on Linux & NVIDIA shield, results discussed in issue 6. Examples Gallery was restructured and now contains 3 examples: QNanoPainter Features, Mouse Event Boxes, and Freehand Painting.

Here’s what they look on Nexus 6:

(best viewed in HD)

So, if you are working with Qt5 and have a need for custom QQuickItems, I warmly recommend checking out QNanoPainter. Thanks to everyone involved!

CMake Daemon for user tools

I’ve been working for quite some time on a daemon mode for CMake in order to make it easier to build advanced tooling for CMake. I made a video about this today:

The general idea is that CMake is started as a long-running process, and can then be communicated with via a JSON protocol.

So, for example, a client sends a request like

  "type": "code_completion_at",
  "line": 50,
  "path": "/home/stephen/dev/src/cmake-browser/CMakeLists.txt",
  "column": 7

and the daemon responds with

Many more features are implemented such as semantic annotation, variable introspection, contextual help etc, all without the client having to implement it themselves.
Aside from the daemon, I implemented a Qt client making use of all of the features, and a Kate plugin to use the debugging features in that editor. This is the subject of my talk at FOSDEM, which I previewed in Berlin last week.
Come to my talk there to learn more!

Trojita 0.6 is released

Hi all,
we are pleased to announce version 0.6 of Trojitá, a fast Qt IMAP e-mail client. This release brings several new features as well as the usual share of bugfixes:

  • Plugin-based infrastructure for the address book, which will allow better integration with other applications
  • Usability improvements in the message composer on several fronts
  • Better keyboard-only usability for those of us who do not touch mouse that often
  • More intuitive message tagging, and support for standardized actions for junk mail
  • Optional sharing of authentication data between IMAP and SMTP
  • Change to using Qt5 by default. This is the last release which still supports Qt4.
  • Improved robustness on unstable network connections
  • The old status bar is now gone to save screen real estate
  • IMAP interoperability fixes
  • Speed improvements

This release has been tagged in git as "v0.6". You can also download a tarball (GPG signature). Prebuilt binaries for multiple distributions are available via the OBS, and so is a Windows installer.

This release is named after the Aegean island Λέσβος (Lesvos). Jan was there for the past five weeks, and he insisted on mentioning this challenging experience.

The Trojitá developers

The 13 Best Qt, QML & V-Play Tutorials and Resources for Beginners

If you’re new to V-Play or coding, then you’re most likely new to Qt and QML too. Qt and QML go hand and hand along with V-Play to help you make cross-platform apps and 2D games in just a few days. Although it’s the easiest way to make your app or game, if you’re just starting out, you might be struggling to get to grips with all the new info you need to take on board.

Thankfully, there is lots of information online to help you out. Learn the differences between V-Play, QML and Qt and take advantage of these tutorials and resources to boost your coding power.

The Differences between Qt, QML and V-Play

The newcomers out there probably have a lot of questions about the differences between these three terms. Qt, QML and V-Play are all separate entities but they all interact when you create your app or game with the V-Play SDK.

Qt is a cross-platform application framework. An application framework is the software that developers use to implement the standard structure of an application. Cross-platform refers to the fact that an application only needs to be written once but works on different systems.

QML is a user interface markup language. A user interface markup language renders and describes graphical user interfaces and controls. QML is a part of the Qt framework. However, as QML was created initially for rapid creation of UIs and animations, you can now use it for writing your app or game logic with a component based approach. Also, you can mix JavaScript with QML easily and make any app or game you like with it.

Like Qt, V-Play is also a cross-platform application framework. The difference however is that V-Play adds a large number of components, elements and other features to the existing Qt framework to make it even easier for developers to make their mobile apps and games.

The Best Qt Tutorials

1.      Getting Started with QML & Qt Creator

Getting started tutorial

Now that you know the differences between the 3 terms, it’s time to get hands-on with them using a short QML tutorial. In order to start learning about V-Play and Qt, you’ll need to open up Qt Creator. This is a powerful IDE, available on all operating systems that will allow you to create cross-platform apps and games.

Qt Creator is included in your V-Play installation and you can learn how to set up your projects using an essential tutorial called Getting Started with QML & Qt Creator. This will guide you through the process of creating a new project and teach you a few simple rules of QML. This tutorial is an absolute must for anyone learning Qt for the first time.

2.      Get Started with V-Play

This is a fun tutorial that shows you how to make your first simple game. Get Started with V-Play teaches you to make a game by introducing you to entities and physics, two essential concepts to understand if you’d like to make mobile games. Once these are covered, you’ll also learn about particle effects, AI and how to use sounds in your games. This is a great tutorial if you’ve never made a game before because it only takes a quarter of an hour to complete.entityconcept-finalgame

3.      Creating QML Objects

Once you know Qt Creator, you can start making your own app or game. The basic elements of any app or game made with Qt or V-Play are QML objects. QML objects include things like buttons, switches, etc. Learning how to implement these objects will stand to you in every part of your coding career so it’s important to understand it before you go any further. Creating QML Objects is a great starting point for beginners, so make sure to check it out. This QML tutorial will teach you the absolute basics of coding with Qt and V-Play.

4.      Communication between QML Objects

In order for your app or game to have a level of functionality, your QML objects must be able to communicate with each other. Communication between QML Objects is a very user-friendly introduction to this subject and will teach you enough to start doing the really enjoyable stuff with your code.

5.      First Steps with QML

first steps with qt

After completing the 3 previous tutorials, there are still a few more concepts to cover in order to gain a comprehensive understanding of Qt, QML and V-Play. The next tutorial to check out will go back over some of the same material covered in the previous tutorials but it will also expose you to some more essential Qt concepts. First Steps with QML is The Qt Company’s own essential getting started tutorial and isn’t to be missed. It brings you through setting up controls within apps and handling user input.

6.    V-Play Tutorials


Although they’re not strictly Qt tutorials, the V-Play tutorials teach you a lot about Qt for both game and app development. You’ll need to download V-Play or add it to your existing Qt installation in order to follow these tutorials. The V-Play tutorials will teach you everything from making a simple Flappy Bird game to making your first functional app. And they also explain the most important Qt and QML features in an application-oriented way.

The Best Qt Resources

7.      Books

Not surprisingly, there are a number of books published on the subject of learning Qt. Although some of the books listed on the Qt Wiki have become a little outdated, Qt 5 Cadaques (alias the QML Book) by Juergen Bocklage-Ryannel and Johan Thelin is an excellent read for anyone learning Qt. It’s free to read online and has a great index so you can jump to exactly what you need to know. Juergen and Johan are passionate about coding with Qt so they’re a great influence for any newcomers out there.

8.      Whitepapers

Even if you’re a beginner, the two whitepapers The Qt Company has published should be of interest to you. Beyond the Code and Driving the User Interface are free to download and cover two very diverse areas.

Beyond the Code is a great piece on how designers and programmers can work together to deliver successful Graphical User Interfaces for embedded systems. Driving the User Interface is a little different as it’s a review of the current trend of adding graphical center-consoles to cars. Check them out and get an idea of the range of projects that can be created with Qt, QML and V-Play.

9.      Demos and Examples

Demos and examples are a great way to learn how to make apps and games. Being able to look through other projects can give you insight into how different elements of a project are made and you can then copy them into your own projects. Look through the V-Play demos and examples to get a feel for what a finished game or mobile app project looks like. You can also have a look at the Qt demos here.

You can also view all of the V-Play game examples and demos in the V-Play Sample Launcher. The Sample Launcher is a stand-alone desktop application that allows you to test all of the open-source demos and examples from V-Play quickly.


10.      Webinars

The Qt Company has released some great webinars over the years to help developers get to grips with certain topics. Two webinars in particular that should be useful to new developers are Getting Started with Qt/C++ Programming and Qt Creator IDE 101. These webinars are targeted at beginners and could be just the resources you need to get started. You can also download these webinars and watch them at a later time offline. Once you’ve watched these, you can move onto Deep Dive – Qt Quick & Qt Quick Controls or one of the other more in-depth webinars.

11.      Qt World Summit Talks

The Qt World Summit is an international event that takes place every year. Qt experts from around the world gather to share and discuss what they’ve learned about Qt in the previous 12 months and what they expect to learn in the coming years. Some of the videos are great for new learners as they include sample code that you can follow along with. These videos in particular are useful for newcomers:

Introduction to Qt Creator by Tobias Hunger

Getting Started with Qt on Android by BogDan Vatra

Qt on IOS A to Z by Mike Krus

The 8 Mistakes of QtQuick Newcomers by Luca Ottaviano, Develer


12.      Qt Quick Best Practices

Best Practices are basically a set of Do’s and Don’ts for developers to ensure that there is a certain quality to written code. The Best Practices are open to discussion and are usually decided on a group basis. You should definitely try to follow Best Practices if you’re releasing an app or game or going to be working with others on a project. It’s a good thing to learn about these Best Practices when you start out coding to avoid developing any bad habits which can be problematic down the road. This one is definitely for those that are serious about learning Qt.

13.      Qt Wiki Learning Portal

The Qt Wiki Learning Portal is the place to go to find even more learning resources. It’s a great collection of examples, demos and resources for improving your Qt coding skills. Although a lot of the listings here are international language versions of other tutorials, there’s still something here for everyone.

Learn to Code with Qt and V-Play!

So now that you’ve got all of the tutorials and resources you need, go and learn to make something great with Qt. And if you find any other cool tutorials or resources, let us know in the comments. You can share this post with your friends and colleagues using the buttons to the left. Thanks for reading!

The post The 13 Best Qt, QML & V-Play Tutorials and Resources for Beginners appeared first on V-Play Game Engine.

Qt Charts 2.1.0 Release

We’re happy to announce that the upcoming Qt 5.6.0 release includes Qt Charts 2.1.0 add-on. This Qt Charts release contains new features and bug fixes based on customer requests.

A short introduction of the module to those of you new to it: Qt Charts is a module that provides a set of easy to use chart components. Different chart types that are available: Line, Spline, Area, Scatter, Bar, Pie, Polar and Box-and-Whiskers Chart.


Example of some chart types available

More information, including examples of Qt Charts usage, can be found from the documentation.

As announced recently, the Qt Add-ons licensing will be changed so that the Qt Charts module becomes available under both GPLv3 and commercial license terms. The source code for the module has already been pushed to With Qt 5.7 release the packages will include a pre-built version of the module and the version numbering for Qt Charts will then be changed so that it follows the Qt versioning.

Performance improvement

The biggest visible improvement done to Qt Charts 2.1.0 is a performance related change. For line and scatter series we’ve added support of accelerated drawing with OpenGL. The change radically improves performance in cases involving large data sets. We’ve added the OpenGL Accelerated Series Example to show how you can enable OpenGL acceleration for QLineSeries and QScatterSeries.


Large data set shown in the OpenGL Accelerated Series Example

New features and functionality in Qt Charts 2.1.0

  • Reverse axis support
  • Possibility to set labels position for QCategory Axis
  • Support for minor ticks to value axis
  • Support for bar series value label angle
  • Points can be replaced and get as a QVector with QXYSeries
  • Duration and easing curve can be set for chart animation
  • Labels clipping can be enabled and disabled
  • Possibility to remove more than one point from QXYSeries
  • Color of the grid can be set with axis
  • mapToPosition and mapToValue methods to ChartView
  • Zooming functions to ChartView to correspond the ones available for QChart
  • Changed signals to scatter series marker size and shape properties

In addition to the above changes there are also several fixes done based on customer reports. For detailed list of changes please see the dist/changes-2.1.0 file included in the source package of Qt Charts.

Qt Charts 2.1.0 is already included as a source package in Qt 5.6 Beta. The final Qt 5.6 release will also include the binaries for this add-on. In Qt 5.6 release the module binaries will still be available only with the commercial packages. Open source users can build the module from the sources. As always, Qt Charts is fully covered by our standard support. Should you have any issues using the module or in case you want to share your ideas for further development, please contact our support team through the Qt Account Support Center.

The post Qt Charts 2.1.0 Release appeared first on Qt Blog.

Changes to Qt Licensing

Some Qt licensing changes were recently announced (1) by The Qt Company. Software licensing can be a complex and confusing issue, and I've already seen some misunderstandings on the mailing lists and forums. Therefore, I thought it would be timely to give some of my thoughts on the changes and what the implications may be for the Qt community.

The usual "I am not a lawyer" disclaimers apply here – nothing I say should be considered legal advice and you should always consult a lawyer when interpreting the various software licenses.

New agreement with the KDE Free Qt Foundation and changes for the open source version

Open Source and the Free Software movement have always played a very important role in Qt’s history. From the very beginning, Qt has been available under both Open Source and commercial licensing terms.

This dual licensing approach has played a major role in turning Qt into the technology it is today. While the commercial business funds the majority of the development work, the open source version has helped us grow the ecosystem of users and provided us with invaluable feedback and contributions improving the product.

KDE Free Qt Foundation

To show our commitment to this dual licensing model, the KDE Free Qt Foundation was founded in 1998. It is a non-profit foundation ensuring that Qt will always be available under open source licensing terms. The agreement that governs this foundation has stayed mainly unchanged over the last 17 years. As a lot of things have changed during these years, we have been working with KDE over the last year to create a new and updated agreement that takes todays realities better into account.

Nowadays, we have many more operating systems that are relevant to end users than we had when the original agreement was signed. To account for this, the updated agreement does not only cover X11 as in the original contract (Android got added around 3 years ago), but all major desktop and mobile operating systems. This includes Mac OS X, Windows, X11, Android, iOS and Windows Phone.

We are also now taking into account the fact that Qt is being developed in the open, with many other people in addition to the ones working for The Qt Company contributing to it. To respect the work of these people, the new contract ensures that all contributions, even if they aren’t yet part of a released version of Qt, are covered by the agreement.

Finally, the new agreement contains updates to the license requirements The Qt Company has when releasing a new version of Qt. Let’s have a look at those.

New license requirements

The new contract changes the licensing requirements for the open source version of Qt. The purpose here has been to bring the licensing of Qt more in line with the philosophy of the Free Software movement.

Free Software is about the freedom of the user to change and modify the code and to redistribute and use these changed and modified versions of the code. LGPL version 2.1 (LGPLv2.1) that we have been using as our main license does not ensure this freedom in the most effective way. For that reason, the Free Software Foundation created version 3 of the GPL (GPLv3) and LGPL (LGPLv3) a couple of years back.

LGPL version 3 differs from version 2.1 in two fundamental aspects. It explicitly protects the right of the end user to not only compile their modifications, but also deploy and run them on the target device. This essentially prevents the creation of fully locked-down devices. Secondly, it explicitly includes a protection against patent claims from the entity distributing code licensed under LGPLv3. These two additions greatly help protect the end users’ freedom when using source code licensed under LGPLv3.

For this reason, we added LGPLv3 as a licensing option to Qt with Qt 5.4 back in 2014, and have published new Qt modules under this license.

In line with this, the new contract with KDE now removes LGPLv2.1 as a required license for the open source version. Instead, it now requires LGPLv3 (and GPLv2 to keep license compatibility with some GPLv2 open source projects) for all existing frameworks and GPLv3 for our tooling and new add-ons.

Changes to our product offering


Starting with Qt 5.7, we are planning to adjust Qt’s open source licensing to be in line with these ideas. At the same time, this allows us to open up the parts of Qt for application development that have previously only been available under commercial terms to the Free Software community, unifying the product.

So Qt 5.7 will not be available under LGPLv2.1 anymore. Instead, we will provide the different parts of Qt under the following licenses:

  • Qt Essentials: All Qt Essentials will from now on be licensed under LGPLv3, GPLv2 and commercial license terms.
  • Qt Add-ons: All Add-ons that are currently available in the open source version of Qt, will in the future be licensed under LGPLv3, GPLv2 and commercial license terms (Qt WebEngine in addition has a LGPLv2.1 requirement due to the 3rd party code from Chromium).Add-ons that were only available under commercial license terms in the past (e.g. Qt Charts and Qt Data Visualization) are now available under both GPLv3 and commercial license terms.
  • Qt Tools and Applications: All tools (Qt Creator, moc, etc.) will in the future be available under commercial license terms and GPLv3. The GPL license comes with two exceptions that ensure that there are no license restrictions on generated code, and that bridging to 3rd party code is still possible.

This means that all parts of Qt for Application Development can be used under the GPLv3. Most parts can additionally be used under the LGPLv3 and GPLv2. Compatibility with GPLv2 will be kept where it is currently in place. All LGPL-licensed libraries inside Qt stay available under LGPLv3.

We believe that this combination of licenses for Qt is the best possible option to grow the Qt ecosystem further in the future.

In the embedded space, LGPLv3 in essence prevents the creation of locked-down devices. So any Qt user will then either help the ecosystem by creating an open device that allows Qt developers to target a larger market, or help the ecosystem by funding further development of the product. For desktop and mobile applications, the changes compared to LGPLv2.1 are smaller, but there are important clarifications for example related to mandatory patent license in case of distributing under LGPLv3 or GPLv3.

Unified product offering

With the contribution of these previously commercial-only modules and tools, we are removing the feature delta between the open source and commercial versions of Qt for Application Development. Publishing these add-ons under GPLv3 makes these available to the Free Software ecosystem, while at the same time keeping the incentives for commercial users to buy a license and help us fund further development of Qt.

The modules newly available to open source users are:

Furthermore we will start work to integrate the Qt Quick Compiler functionality into the Qt QML module, targeting the Qt 5.8 release. At that point it will be available under LGPLv3/GPLv2/commercial license (the currently available Qt Quick Compiler will remain commercial-only for Qt version prior to Qt 5.8).

The source code for many of the modules has already been pushed to and we will push the remaining items in the coming days.

No changes to Qt 5.6 and Qt for Device Creation

Qt 5.6 and earlier versions will not be changed and continues to be available under the old licensing terms. Qt 5.6 is a long-term supported release, supported for three years after its release. We believe that this will give all users of the open source version enough time to adjust to the new licensing terms.

There are also no changes to Qt for Device Creation, which remains a commercial-only product.

Changes for commercial license holders?

It’s important to note that there are no changes to the commercially licensed version of Qt. But, we are convinced that these changes to the open source version will result in indirect benefits also for our commercial customers.

We believe these changes to lead to a better and more feature-rich Qt. This is due to the fact that the previously commercial only parts of Qt for Application Development will receive much broader testing and hopefully also contributions from the ecosystem. In addition, this change will help us extend the investments of The Qt Company into Qt and allow The Qt Company to focus more of its investments into the core part of the product.

Qt for Start-Ups

Over the last years, we have heard comments from many small companies and start-ups telling us that they would love to use the commercial version of Qt, but can’t afford the price of a full license. For these companies, we will in the coming months introduce a commercial start-up license for Qt for Application Development. This reduced-price offering will be limited to small companies and start-ups with annual revenue less than $100K.

Summing it all up

This change is the last step in a process we started about 1.5 years ago when we announced the one unified web site ( for Qt and that certain parts of Qt will only be available under LGPLv3 in the future. With this change, we can now fully unify our product offering. In the future, we will have one product called Qt for Application Development that comes with both commercial and open source licensing options.

The new licensing of the open source version of Qt is now much better aligned with our vision for Qt and the ecosystem around it. It is focused around the idea of a growing ecosystem where the open source version helps us extend the outreach and set of addressable devices for Qt application developers, and the commercial version generates the revenue to push the development of Qt as a product forward.

Feel free to also have a look at the corresponding announcement from KDE.

Also, for further information about the license change and Qt licensing in general, please see our updated licensing FAQ.

The post New agreement with the KDE Free Qt Foundation and changes for the open source version appeared first on Qt Blog.

Eight Golden Rules for Success in UX Design

While I missed the recent 2015 Qt World Summit, I have been to and presented at Qt Dev Days for the previous three years running.  Each year, I presented two topics.  The first was related to a recent project or piece of software that we had been working on, including such fun items as an In-Vehicle Infotainment (IVI) system for Intel or the latest in voice recognition and gesture-based interfaces.  My second talk was actually the same each year: “Introduction to User Experience for Engineers”.

How to Support V-Play on Your Raspberry Pi!

This guest post by Peter Bouda explains how he got V-Play’s Flappy Bird game working on a Raspberry Pi and the birth of his project, μbrew gaming.

For a few months, I spent a lot of my free time on Raspberry Pi projects and thought that the tool provided some amazing opportunities to learn about embedded devices. I’ve always been very interested in building hardware and low-level programming, especially graphics programming and game development, pretty much since I programmed 3D graphics on my Intel 80286 in Assembler in the 1990s.

Since around 2008, I also developed mobile applications based on the Qt framework, and was able to run a custom port of Qt 4.8 and the Qt Asteroids demo on the Dingoo A320 game console. Running Qt games on my own mobile game console based on an embedded platform  was the idea that began to grow in my mind…

Raspberry Pi goes to Vienna

After following the development of V-Play for more than a year I knew that V-Play and the Qt ecosystem in general provided some great development tools that already supported embedded development. I had already developed some Qt applications that ran on my own embedded Linux on the Raspberry Pi, which was really easy to do with the help of the Buildroot project.

“So what else do I need to do to run V-Play games?” I thought. I decided to get in touch with the V-Play guys and asked them if they were interested in a Raspberry Pi port of the V-Play libraries. They were definitely interested! I was planning a trip to Munich at the time and I’d never visited Vienna before, so I offered to come to Vienna to visit the V-Play office and meet the team.

Those were two exciting days in Vienna. Not only because the city itself is definitely worth a visit, but because I only managed to finish the port during the last few hours of my stay. I had prepared everything in the Buildroot environment, but still had to solve some issues with the build process of V-Play.

In the end, I finally played some Flappy Bird on the Raspberry Pi :-) Thanks again to the team for the hospitality and the opportunity to do something cool like this!

Gamepad and remote deployment

As soon as I returned home to Portugal I still had two things to finish: Gamepad support and remote deployment via Qt Creator. I understood that V-Play doesn’t support physical gamepads yet however Chris told me that gamepad support is on the list of future V-Play features. They do have a really nice virtual gamepad, but for this project I wanted to start without a touch screen.


I searched the Internet and soon found the QtGamepad module on Qt Labs. Nice! I cross-compiled it with the Buildroot toolchain, added a few lines of Gamepad-QML code to the Flappy Bird game and the one-button-flap functionality was working.

The last thing to do was to enable remote deployment via Qt Creator, which JavaScript supported now with the help of an OpenSSH server in the embedded Linux. Now you can develop V-Play games on your desktop within Qt Creator, then just press play and the game runs on your Raspberry Pi!

Do-It-Yourself: μbrew gaming

The project around our DIY game console is now called “μbrew“. You can find a detailed step-by-step tutorial to build the embedded Linux system with V-Play and the Buildroot cross-compilation toolchain on our website!


It’s the first step to a DIY mobile game console, but an important one. V-Play is an amazing cornerstone for game development in general, and now it works on the first embedded platform!

Our goal is to support open source and independent projects around DIY gaming and we hope to contribute our part to promote those great projects, like V-Play, in the future.

By the way, if you need to run any other Qt application on the Raspberry Pi, the Buildroot environment is available in a separate GitHub project and allows you to run Qt applications on the Raspberry Pi in a custom and minimal embedded Linux system.

Build and run a game with V-Play

After reading this section you will be able to compile V-Play games with Qt Creator and run them on your Raspberry Pi. Make sure that you successfully installed the μbrew development.

1. Clone the μbrew Flappy Bird repository

As an example game, we will build and run the Flappy Bird demo that is also part of V-Play and that’s covered in an excellent tutorial on the V-Play website. For μbrew we will use a specific fork of the code from the μbrew repository, as this version supports gamepads and contains landscape mode graphics for monitors. To clone the repository, open a terminal and type:

$ git clone

This will download the μbrew code of Flappy Bird.

2. Open the project in Qt Creator

Next, open the project file of Flappy Bird in Qt Creator. Start Qt Creator that came with V-Play and choose File -> Open File or Project… from the menu. Browse to the Flappy Bird folder and open

Qt Creator will open a page with the title “Configure Project”. Make sure you select the Raspberry Pi kit that you created for the μbrew development kit, as shown in this screenshot:

Configure Project

Then click on “Configure Project” to close the dialog and save your settings. Qt Creator will now parse the project files and generate Makefiles to compile the game later. Before we run the project, we still have to set the working directory on the Raspberry Pi in the project settings. Click on “Projects” in the left pane of Qt Creator and choose the “Run” tab of the Raspberry Pi kit:

Run Settings

Under the heading “Run” you will find the setting for the Working directory. Enter /opt/FlappyBird into the input field:


You are now ready to start the game on the Raspberry Pi. Make sure the Raspberry Pi is turned on and accessible over the local network. Qt Creator will try to access the remote device via SSH, so make sure the login works.

If you followed the instructions to install the μbrew development kit, the connection settings are already stored in Qt Creator as part of the Qt kit. Click on the “Run” button of Qt Creator in the lower left corner (the big green Play button). Qt Creator will now compile, deploy and run the game on the Raspberry Pi!

Feel free to play around with the Flappy Bird code to make yourself familiar with Qt Creator and the development process. Whenever you change some code now you can simply press “Run”, and the modified version will be started on the Raspberry Pi. Happy coding and gaming!

Raspberry Pi Support for V-Play

We’d like to thank Peter for doing this proof-of-concept of V-Play running on a Raspberry Pi and for taking the time to write this post. We’d also like to wish him a happy new year and best of luck with all his projects in 2016!

Would you like to run your game on the Raspberry Pi too? Then get in touch with us here to request access.

Get Raspberry Pi Access!

If you enjoyed reading, then please make sure to tell your friends and colleagues using the buttons to the left. Thanks for reading!

The post How to Support V-Play on Your Raspberry Pi! appeared first on V-Play Game Engine.

Injeqt 1.1 is coming

After some hiatus (summer is time for riding a bike, not for spending evenings at home writing open-source code) I've moved Kadu few steps forward. New version - 4.0 - will require some more functionalities from Injeqt dependency injection library. So a few new had been added. Most of them for plugin support. I'll give a short description of each of them and then show you how these works together.


I've promised subinjectors when Injeqt 1.0 was released. And now these are available. In short - you can create new injector with new modules and classes that also gains all knowledge and instance of another injector (or injectors).

In Kadu this means that each plugin can new have its own injector and use all of Kadu classes and services in a nice way (using INJEQT_SET setters).


It is quite frequent to run some code after all required objects were injected into newly created one. Think of that as of two-step initialization (in that case it is not as bad as most people describe it, do not be scared). Slots marked with INJEQT_INIT tag will do just that - be called after all INJEQT_SET/INJEQT_SETTER slots.

INJEQT_DONE marked slots that will be called before any object created by injector is destructed. It allows for cleanup, writing files do disc and do other stuff without worrying about availability of other objects (such code can not be run from destructors, because Injeqt does not guarantee anything about order of object destruction).

In Kadu INJEQT_INIT methods are used to connects slots and signals of services and to do loading/storing data.


It is a new name for INJEQT_SETTER. Just to match grammar of INJEQT_INIT and INJEQT_DONE.


Now Injeqt allows you to select when given object will be instantiated. If it is tagged with INJEQT_INSTANCE_ON_DEMAND (default) the behavior will be the same as with Injeqt 1.0 - object will be first instantiated when it is needed. If class is tagged with INJEQT_INSTANCE_IMMEDIATE - object will be instantiated as soon as possible (before injeqt::injector constructor finishes). Useful for services that works on their own using signals from other services. In Kadu all main plugin objects are marked with INJEQT_INSTANCE_IMMEDIATE, so there is no need to manually create them after plugin is loaded and plugin's injector is created.

inject_into method

Sometimes you create object manually, but still want to put injectable objects into it. Just call injeqt::injector::injeqt_into(QObjec *) on it and you are done.

In Kadu this is mainly used to allow access to Kadu services by dynamically created widgets.

Usage in Kadu

Now I'll show you real-life example of how it all works together.

Lets get a quick overview on how Kadu plugins were loaded in the past (like 3.x releases).

class PluginRootComponent
virtual bool init() = 0;
virtual void done() = 0;

Q_DECLARE_INTERFACE(PluginRootComponent, "im.kadu.PluginRootComponent")
This is the class that each plugin must implement and export. You can see example implementation for OTR encryption plugin in otr-plugin.cpp file. As you can see it uses init() method to initialize its own injector, connect some of its signals and slots (unfortunately, Injeqt can not do it for you yet). Some objects from Kadu core are retrieved using Core::instance() calls (this is one thing that I'm fixing currently). And the done() method is used to remove OTR objects from Kadu services. Fortunately the Injeqt takes care of objects created with OTR injector. The last important part are PluginRootComponentHandler class:
PluginRootComponent *pluginRootComponent) :

PluginRootComponentHandler::~PluginRootComponentHandler() noexcept
And the ActivePlugin class:
ActivePlugin::ActivePlugin(const QString &pluginName) :
So, finally, the steps are:
  1. load .dll or .so file
  2. create PluginRootComponent instance from it using Qt QPluginLoader
  3. call init() method on the instance, it creates its own objects and connects to Kadu core classes with awkward ::instance() calls (either Core::instance()->className() or className::instance()
  4. before unloading call done() method
In comparison, Kadu 4.x uses different method for that. PluginRootComponent is replaced with PluginModulesFactory:
class KADUAPI PluginModulesFactory : public QObject

explicit PluginModulesFactory(QObject *parent = nullptr);
virtual ~PluginModulesFactory();

virtual std::vector<std::unique_ptr<injeqt::module>>
createPluginModules() const = 0;
virtual QString parentInjectorName() const;


Q_DECLARE_INTERFACE(PluginModulesFactory, "im.kadu.PluginModulesFactory")
Its only job is to create list of Injeqt modules. Implementation of this class is usually fairly simple:
OtrPluginModulesFactory::createPluginModules() const
auto modules = std::vector<std::unique_ptr<injeqt::module>>{};

return modules;
Then the injector is created and stored in PluginLoader class using following code:
injeqt::injector{std::vector<injeqt::injector *>{parentInjector},
And that is all that is needed from Kadu core. Now please look at new otr-plugin-object.h and otr-plugin-object.cpp files. There are few things to be seen in OtrPluginObject class:
  1. it is marked with INJEQT_INSTANCE_IMMEDIATE - it means it will be instantiated as soon as plugin is loaded and injector is created
  2. it has INJEQT_SET slots with Otr* objects (that come from OtrModule) and with other objects that comes from Kadu core - it is possible because of adding parentInjector into injeqt::injector constructor - we got rid of some of ::instance() calls
  3. it has INJEQT_INIT and INJEQT_DONE methods to set up and shut down the plugin - these two are called by Injeqt and replaces manually called init() and done() methods of PluginRootComponent


I think that Injeqt is going into good direction. It makes working with such a big project as Kadu a bit easier each time it is itself improved. In future I hope for two more things to be implemented in it: INJEQT_SIGNAL and INJEQT_SLOT tags that will allow to automatically connects slots and signals of Injeqt-created objects and something like INJEQT_ADD and INJEQT_REMOVE to simplify creating repository/registry-like classes. Maybe one of these feature will be added to Injeqt 1.2. After adding both of them, I could remove most of INJEQT_INIT and INJEQT_DONE methods from plugins.

Qt 3D: The Asset Conditioning Pipeline

by Andy Nichols (nezticle) (Qt Blog)

Qt 3D development has been coming along nicely and is scheduled to be released with Qt 5.7.  One of the issues we face with offering a high-level 3D rendering API is facilitating the asset conditioning pipeline.  When dealing with 3D assets, there is a need to process the assets created in digital content creation applications like Maya, 3ds Max, or Blender into a format that makes sense for the rendering engine.  This is analogous to 2D asset conditioning pipeline where a designer creates an image in Adobe Illustrator (an .ai file), and before you use it in your application you convert it to PNG format.

What is an Asset Conditioning Pipeline?

Before diving into the implementation details of Qt 3D its worth explaining what an asset conditioning pipeline is.  Assets created in digital content creation applications are typically stored in data formats that reflect the needs and capabilities of that tool, and not the application you intend to use them.  The saved file will likely contain an abundance of extra data that is not relevant to your application leading to a larger storage need, as well as more time to load and put into use at runtime.  As an example, if we look at the data stored in a Blender file (.blend) in addition to containing geometry data, there is information specific to the Blender editor and renderer.  Information like the layouts of the editor, undo stack, modifiers, levels of detail etc.  There is also other really expensive things like high polygon models that are sculpted and used for baking additional assets like normal maps.  So even for a very simple model the file saved by the editor could have much unnecessary data that just takes up space in your deployment bundle, and in some cases the data it has is not in the most efficient format for how we will use it.

Many 3D content creation tools have the capability to export into file interchange formats like COLLADA.  These exporters are useful in the sense that they can strip out much of the excess data that is tool specific.  But while formats like COLLADA makes it easier to transfer 3D assets between content creation tools, they still don’t store data in a format facilitating efficient loading and usage. In addition, getting assets in the desired format is just not always possible. For instance, receiving a 40 MB car model in OBJ format from the design department is less than ideal, to put it mildly, but sometimes unavoidable in practice. It would be nice if developers could progress with the project regardless, without having to deal with asset loading times of several minutes.

Given those issues, the asset conditioning pipeline is responsible for transforming that asset file into a format that is useful for that intended task.  So stripping the asset of unnecessary data, and converting what is left to a format that can be easily and efficiently used by the rendering engine.

How does Qt 3D facilitate the asset conditioning pipeline?

Qt 3D is quite flexible in what assets can be used at runtime.  It is now possible to use any of the above formats directly in your application at runtime, despite the inefficiency. This is enabled by use of the Open Asset Import Library (libassimp).  We bundle this as a 3rd party library with the Qt 3D module and provide a scene parser plugin that uses it to load a Qt 3D scene from an asset file.  This approach can be seen as using non-conditioned assets, or runtime conditioned assets, and will not be ideal for resource sensitive applications, especially on mobile and embedded platforms.

In addition to the Assimp scene parser plugin, we also have a plugin for loading GL Transmission Format (glTF) assets.  The glTF format like the COLLADA format is a Khronos-defined (draft) standard, but unlike COLLADA, glTF is designed for the efficient transmission and loading of 3D scenes and models for applications.  Assets bundled as glTF have geometry data, textures, and shaders all bundled in such a way that it is easy for Qt 3D to upload those assets to the GPU, and make use of them in the Qt 3D scene.  Because of this we choose glTF as the format to use for our asset conditioning tool.

Introducing qgltf

To get a quick overview, you may want to watch the recording of the lightning talk from Qt World Summit 2015 in Berlin:

The Qt tool qgltf is an application that is bundled with the Qt 3D module.  It is a host tool in the same way as qmake or moc, in that is built and run on the host machine.  The purpose of qgltf is to take an arbitrary 3D asset created with a digital content creation tool, and convert to glTF which will be loaded into a Qt 3D scene by the above mentioned glTF scene parser plugin.  By using the bundled Open Asset Importer Library in the qgltf tool, we are able to convert the same files Assimp scene parser can load into glTF for efficient loading. This also means that the number of dependencies for the Qt libraries on the target system can be reduced. This can be important for embedded systems in particular: there is no need to ship potentially large 3rd party libraries together with Qt when the assets are baked into a common, efficient format during build time.   

There are existing converter tools (for example COLLADA2GLTF) available that can convert 3D assets to glTF, and in some cases the output of these will be usable as-is by the Qt 3D’s glTF scene parser plugin.  However, besides the obvious issue of COLLADA not being the only commonly used format, glTF’s focus is on WebGL at the moment.  In Qt 3D we have support for all current OpenGL and OpenGL ES versions, which means that shaders for a given GLSL version built into the assets can be problematic. More importantly, it will often be desirable to use Qt 3D’s built-in materials instead of providing custom shaders (generated by the converter tool) for every asset. This way models and scenes can participate in Qt 3D’s standard lighting system. Therefore, in addition to a set of basic built-in shaders, qgltf promotes the use of extensions like KHR_materials_common which allow models to use Qt 3D’s own standard materials instead of asset-provided shaders and technique descriptions.

By using the qgltf tool we also have the possibility to bring further optimizations to the generated files.  Assets in glTF typically consist of several different standalone files.  The main asset file is the .gltf file which is a JSON file can that actually describes the scene itself.  With qgltf we can output this as a binary JSON file, or even a compressed version of that to get even more efficient loading times.  Generating tangent vectors and scaling vertices during build time are also supported. In case Qt 3D’s built-in materials are not deemed suitable, qgltf can generate techniques and shaders both for GLSL 1.00 and version 150 (suitable for OpenGL 3.2+ core profile contexts). Another experimental feature qgltf can provide is automatic compression of texture assets.  So if you have several texture files that are in PNG format, and you are deploying to a device that supports ETC1 compressed images, qgltf will make sure the asset it generates also contains and uses those compressed textures.

It is also important to point out that not every possible feature of glTF is in use: things that are better defined through Qt’s, QML’s and Qt 3D’s own powerful facilities are left out from the baked assets. This includes lights and animations (skeletal animations are on the roadmap for future releases, though). So in short, the tool’s focus is on converting and baking the parts of the assets that matter, nothing more, nothing less, into a format that is most efficient to deploy and load at runtime, even on I/O-bound embedded systems.

Usage of qgltf

Keeping with our tradition of flexibility, you also have a few options on how you can use the qgltf tool to best fit your workflow.  First can use it as a standalone command line tool that you can include in your existing asset import pipeline.  If you have the Qt 3D module installed alongside your Qt installation the qgltf tool exists at the same path as the other Qt tools (qmake, moc, uic).  If you are using qmake as your build system you also have the possibility to have qgltf run automatically when your application builds.  To do this you simply need to list your 3D model assets as followed in one of your qmake project files:

# 3D assets
QT3D_MODELS += assets/3d/car.obj
# Parameters for qgltf (use binary JSON and rely on Qt 3D's built-in materials)
# load the qgltf qmake feature

This will convert the OBJ file into a glTF format file, and add it to a Qt resource file (.qrc) together with all the geometry and image files.  To make use of that model in your Qt 3D application you just need to load the generated file by setting it as the source in your SceneLoader. Everything else is managed automatically by the build system.

SceneLoader {
    source: “qrc:/models/car.qgltf”

What does the future hold?

Qt 3D is still quite new and under heavy development so there are still many possibilities that can be explored with regards to asset conditioning and other tooling.  We could for example have additional measures in qgltf that optimize the original mesh when possible.  We have also been looking into the possibility of generating a QML file along with the glTF asset that can facilitate the loading and easy access of elements (sub-meshes, materials, etc.) within the models and the scene.  And of course if you have any feedback or ideas we would love to hear them.

The post Qt 3D: The Asset Conditioning Pipeline appeared first on Qt Blog.

Porting from Qt 4 to 5

Looking for a New Year's resolution for 2016?

Official support for Qt version 4 came to an end in December 2015. Qt version 5 first came out in 2013 and is currently at version 5.5.1, with the 5.6.0 release coming early this year. Qt 5.6.0 will be the first LTS (Long Term Support) release, with a commitment to be supported for three years.

If you are still using Qt 4, it really is time to start thinking about migrating your code to Qt 5.

A C++ project without Qt

My primary language is Smalltalk (Pharo and GNU Smalltalk) and I didn't write much C++1x code yet and for a new project I decided to use C++ and experiment. The task was rather simple, receive a message, check if this message type needs to be re-written, start to parse it, make a MongoDB look-up, patch it, send it.

While looking for MongoDB drivers for Qt I only found the pure C++ driver that is working with std::string, exceptions and only offers a blocking interface. At this point I decided to see how painful using stl is these days and opted for a pure stl project. Many years ago the only online documentation came from SGI, there were no examples, no autocompletion in editors, etc...

The application is relatively trivial. It is using lambdas to hook two components (the receiver and the patcher) together, it is using std::thread with lambdas to spawn worker threads because of the blocking interface of the database driver, std::chrono for some ad-hoc StatsD code to add event counters and performance monitoring.

So how did this experiment go?

The C++11/C++14 documentation that is available has improved over the old times, it is still below the quality of the Qt documentation.

Once deploying this on Debian I immediately had odd crashes and I blame ABI issues as my application used C++1x but the mongo-cxx-driver was apparently not using it. I ended up packaging the latest stable ("legacy") standalone driver for debian and made sure it is compiled with C++1x.

The std::chrono API has potential (as it allows me to control the resolution) but the API, specially in C++11 without the new literals, makes easy things difficult. All I wanted was something like QTimer::elapsed() or QElapsedTimer::elapsed(). So I think the Qt API is better designed for this usecase (my measurement resolution is milliseconds and not picoseconds).

For socket code I was using pure C/libc. As my database code was blocking I could make my socket code blocking as well.

I normally use vim but when working with an unknown API I totally enjoy the comfort QtCreator is providing. I was able to jump to the header files and explore the interface. I think it has saved me quite some time while wrangling with the stl.

New languages come with their own build tools these days (Rust/Cargo, Ruby/Rake, ...) and C++1x doesn't have anything to offer here. The options I considered where autotools, CMake or qmake. I think autotools are overkill here, I dislike CMake for various reasons and I like the simplicity of qmake.

In the past I had played with the Google C++ Unittest framework and actually liked it a lot. These days one is asked to copy and paste the framework into the code base. It is an ongoing struggle if one should embed third party libraries or not but as my application is rather small I decided it is a no go. I have used and enjoyed the Qt testlib. So my STL only application is tested using QObject and QCoreApplication.


The STL (and the documentation) has improved. I still prefer the API design of Qt and when not just interfacing with an library that is using std::string Qt is still my first choice (as it provides event loops, signals/slots, networking, http, etc.).

Anti-Patterns of User Experience Design

Some time ago, I wrote a post about the use of patterns in user interface (UI) design.  The idea is that, when one solves problems for a living, over the years the same problems will crop up, and similar solutions will be re-used. The context may change, but a solution that worked well at one point may also end up working well for a new problem.  Having the experience to recognize these patterns and not have to re-invent the wheel each time is what makes one an “expert”.

QNanoPainter Available!

About 2.5 months ago I introduced QNanoPainter project for implementing custom QQuickItems. We’ve been really busy (and continue to be so) with other things but took now the time to push QNanoPainter publicly available for wider audience in here:

It’s not ready (as software never is), but already quite capable for serious kicking of tires. Just clone it, build with Qt Creator / qmake and run the provided examples. And when you want to try implementing own items, straightforward instructions to get started are available at front-page README.

If you dig it and want to assist in improving QNanoPainter, here are few ideas for patches:

  • We have tested QNanoPainter on OS X, Linux, Android and iOS. What’s missing at least is making it work on Windows (with dynamic OpenGL build of Qt).
  • Documentation with QDoc has been started but it’s not complete. There are plenty of ”TODO: Write more documentation here” comments in classes and documentation could overall be improved and styled.
  • Current NanoVG version used is from fork at bfbac9a35e, with some additions. Custom additions are marked with ”// ### Added”. Some reasons to go with this fork for now instead of upstream are discussed in What should be done is to update NanoVG to some latest version, apply additions and test properly. Maybe own NanoVG fork with additions should be maintained?
  • Instead of stb_truetype and stb_image code could be ported to use Qt for images and texts. I think at least text rendering would require private Qt headers and additions in Qt side, so may not be that straightforward.
  • Bugfixes!

We received some good comments already and hopefully now more & patches when sources are publicly available. I’ll write some more blog posts later, but now.. Clone!