Wayland and Qt 5.4

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

There's a few "buts", though.

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

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

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

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

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

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

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

Qt Fix and Polish Week

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

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

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

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

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

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

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

Thanks a lot to all participants!

Cake with Qt logo and bug on the icing

Grantlee 0.5.0 (codename Auf 2 Hochzeiten tanzen) now available

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

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

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

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

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

Testing Qt and QML applications @ Qt Developer Days

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

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

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

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

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

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

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

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

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

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

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

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

One Unified Site | www.qt.io

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

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

A great new offering for Indie Mobile Developers

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

Qt 5.3.2 and Qt Creator 3.2.1

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

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

Qt 5.3.2 Released with Qt Creator 3.2.1

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

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

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

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

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

Qt Quick Compiler 1.1

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

Qt Quick Enterprise Controls 1.2

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

The Tumbler QML element

Behold! The Tumbler is here!

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

Qt Purchasing 1.0.1

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

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

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


Qt Creator 3.2.1 released

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

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

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

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

Kiosks and Learnable Interfaces

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

What's coming to Green Island: part 1

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

Multi output support: part 1

Green Island now supports multiple outputs.

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

How does it work?

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

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

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

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

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

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

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

Multi output support: part 2

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

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

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

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

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

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

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

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

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

Unresponsive applications

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

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

Qt Cloud Services introduces Managed Application Runtimes in public beta

Today is a great day for us and Qt Cloud Services.  After a successful early access period, we have now released Managed Application Runtime (“MAR”) to the whole Qt ecosystem. It is a huge leap forward in our efforts to create a complete set of development tools for connected applications.

Managed Application Runtime is an application platform-as-a-service (PaaS). It provides runtime and essential tools needed for agile server-side application development. In addition to our Enginio Data Storage and Managed Websocket Services, any application logic can now also run on the cloud side. This enables unlimited possibilities to develop and host connected applications with Qt tools. Here are some of the key features:

  • It’s Easy to Develop. Use your favorite programming language for server-side development. Choose Qt, Node.js, Ruby or other supported languages. Need a database? We have MongoDB, MySQL and Redis for you.
  • It’s Great to Deploy. You can use the Git version control tool to deploy your application. Just commit your changes and make a git push. The application will be built and deployed automatically without any downtime.
  • It’s Amazing to Scale. Server-side applications need to perform flawlessly regardless of load or usage patterns. We have made it possible for you to adjust the number of instances powering your application in real time.

The development and maintenance of reliable and scalable server infrastructure for connected application can be very time consuming and expensive. With Managed Application Runtime you don’t need to worry about the server infrastructure.

We are also happy to introduce a new “qtc” command-line tool which can be used to manage and access your cloud resources, application scaling, access logs and more. It is an essential tool for server-side developers and dev ops people working with Qt Cloud Services.

New Terms of Service and Pricing

The Qt Cloud Services Terms of Service and pricing are also updated to support the new features we’re rolling out and to allow you to subscribe to paid services.

Get Started Today

Please read through the Managed Application Runtime (“MAR”) getting started guide to get your application to run on the cloud side. You just need a valid Qt Account to start using the service in the management console. The usage is free up to certain limits. All existing customers and other Qt account holders have access to try it out now!

If you have any questions or suggestions, you can always contact us via our support helpdesk or submit your question to the community forums. Thank you in advance.

profiling is not understanding

When software goes slow, generally, the first reaction is to profile. This might be done through system tools (like Instruments on OS X, perf/valgrind/etc on Linux, VTune, etc). This is fine and good, but just because you have the output of a tool does not necessarily correlate to understanding what is going on.

This might seem like an obvious distinction, but all too often, efforts at improving performance focus on the small picture ("this thing here is slow") and not the bigger picture ("why is this so slow"). At Jolla, I had the pleasure of running into one such instance of this, together with Gunnar Sletta, my esteemed colleague, and friend.

As those of you who are familiar with Jolla may know, we had been working on upgrading to a newer Qt release. This also involved quite a bit of work for us, both in properly upstreaming work we had done on the hurry to the late-2013 release, and in isolating problems and fixing them properly in newer code (the new scenegraph renderer, and the v4 javascript engine in particular have been an interesting ride to get both at once!).

As a part of this work, we noted that touch handling was quite slow (something which we had worked around for our initial release, but now wanted to solve properly). This was due to the touch driver on the Jolla introducing touchpoints faster than the display was updating, that is, while the display might be updating at 57 hz (yes, the Jolla is weird, it doesn't do 60 hz) - we might be getting input events a lot more frequently than that.

This was, in turn, causing QtQuick to run touch processing (involving costly item traversals, as well as the actual processing of touch handling) a lot more frequently than the display was updating. As these took so much time, this in turn slowed rendering down, meaning even more touch handling was going on per frame. A really ugly situation.

Figure 1: Event tracing inside the Sailfish OS Compositor
Figure 1 demonstrates this happening at the compositor level. The bottom slice (titled "QThread") is the event delivery thread, responsible for reading events from evdev The peaks there are - naturally - when events are being read in. The top thread is the GUI thread, and the high peaks there are touch events being processed and delivered to the right QtQuick item (in this case, a Wayland client, we'll get to that later). The middle slice is the compositor's scenegraph rendering (using QtQuick).

With the explanation out of the way, let's look at the details a bit more. It's obvious that the event thread is regularly delivering events at around-but-not-quite twice the display update. Our frame preparation on the GUI thread looks good, despite the too-frequent occurrence of event delivery, though, and the render thread is coping too.

But this isn't a major surprise - the compositor in this case is dead simple (just showing a fullscreen client). What about the client? Let's take a look at it over the same timeframe...

Figure 2: Event tracing for the client (Silica's component gallery, in this case)
Figure 2 focuses on two threads in the client: the render thread (top), and the GUI thread (bottom). Touch events are delivered on the GUI thread, QtQuick processes them there while preparing the next frame for the render thread.

Here, it's very clear that touch processing is happening way too often, and worse than that, it's taking a very long time (each touch event's processing is taking ~4ms), not leaving much time for rendering - and this was on a completely unloaded device. In a more complicated client still, this impact would be much, much worse, leading to frame skipping (which we saw, on some other applications).

Going back to my original introduction here, if we had used traditional profiling techniques, we'd have seen that touch handling/preparation to render was taking a really long time. And we might have focused on optimizing that. Instead, thanks to some out-of-the-box thinking, we looked at the overall structure of application flow, and were able to see the real problem: doing extra work that wasn't necessary.

As an aside to this, I'm happy to announce that we worked out a neat solution to this: QtQuick now doesn't immediately process touch events, instead, choosing to wait until it is about to prepare the next frame for display - as well as "compressing" them to only deal with the minimal number of sensible touch updates per frame. This should have no real impact on any hardware where touch delivery was occurring at a sensible rate, but for any hardware where touch was previously delivering too fast, this will no longer be a problem as of Qt 5.4.

(Thanks to Gunnar & myself for the fix, Carsten & Mikko for opening my eyes about performance tooling, and Jolla for sponsoring this work.

P.S. If you're looking for performance experts, Qt/QML/etc expertise or all round awesome, Gunnar and myself are currently interested in hearing from you.)

Squish tip of the week: How to know what code your testing actually exercises

Did you know Squish GUI Tester and Squish Coco can work together to reveal more about your testing?

Integrate your testing with Squish Coco to answer these questions:
  • How many of our tests are redundant?
  • What areas of our application are the tests not reaching?
  • If I only had a given amount of time to execute as many tests as possible, which tests would you choose?
  • …?

What will this simple integration reveal about your testing coverage?

Read Measuring code coverage using Squish Coco & Squish GUI Tester to get started!

KDE Akademy 2014 – Welcome, new KDE board!

Akademy 2014 is still in full swing in Brno in the Czech Republic with the traditional hack week that started on Monday. At about 200 participants it was well attended and organized. This years conference will very likely mark a milestone of change for KDE – a new board was elected, and a strategy discussion was started that will affect the direction and development of the KDE community for a decent amount of time. When I traveled home from Akademy 2014 on the train from Brno to Berlin, I personally felt a sense of satisfaction, because the community has managed to steer clear of the dangers of bike shedding about the board succession, and is accepting the change imposed by a shifting environment as a positive force.

Akademy 2014

Of the five positions of the KDE e.V. board, three were up for re-election. Lydia Pintscher’s first term on the board lapsed, and she ran for re-election. Marta Rybczyńska took over mid-term when Agustin Benito Bethencourt stepped down from the board, and stood for election for a regular board seat. Because of their proven commitment and steady hand, both won their seats with ease. Together with Albert Astal Cid and Pradeepto Bhattacharya they will provide the experience and continuity needed for the board to perform it’s function. The remaining board seat was contested between Jos Poortvliet and Aleix Pol, both long-standing and committed KDE community members. It was won in a tight race by Aleix Pol. He will bring his experience from building KDE Spain to the mothership of KDE e.V. Good luck to him and the whole new board, and many thanks to Jos for standing up for election.

A photo from the keynote by Sascha Meinrath

The new board is facing a number of challenges. Some are simply of operational nature, like finding a new office manager and other permanent staff. More significantly, there are some long-term shifts that need managing. In a time when Free Software contributions in an industrial setting are becoming more and more institutionalized, a volunteer driven, decentralized community like KDE has to adapt its ways of fundraising and attracting and retaining contributors. This is of course not the reponsibility of the board alone, but the board does set the tone and priorities as stewards. It is great and promising to see fresh and driven people joining the board, adding new attitudes and ways to get things done. I would like to extend ginormous amounts of gratefulness, thanks and hugging to Cornelius Schumacher, who stepped down from the board after serving on it for nine (9, sic!) years. For a long time, he has with his particular calm and well-reflected opinions been solid as a rock as the president of KDE e.V. He leaves pretty big shoes to fill for the new president.

Which leaves the question of what the structure of the new board is. It was announced to the KDE Community mailing list by Albert Astal Cid:

  • Pradeepto Bhattacharya – board member
  • Albert Astals Cid – board member
  • Aleix Pol – vice president
  • Marta Rybczynska – treasurer and vice president
  • Lydia Pintscher – president

Good luck again to all of them. Quite impressively, our board is 40% female, 60% male. With five board members an exact 50/50 ration is hard to achieve, so in my opinion, anything between forty and sixty percent should count as properly balanced, gender-wise. This again serves to illustrate the composition of contributors that makes KDE great.

The new board will need all the support from the KDE contributors that it can get. It may be worth to point out that all board members are volunteers and do not receive any remuneration for their work. If you want to pitch in and help, consider joining the kde-community@kde.org mailing list. If you are already a KDE contributor, you may want to ask to be a member of KDE e.V. And if you are a member, many thanks for your contributions, and keep going!

Filed under: Coding, CreativeDestruction, English, FLOSS, KDE, OSS, Qt Tagged: Akademy, Creative Destruction, FLOSS, free software communities, KDE, kde community, Open by Default, technology

Qt Weekly #19: QOpenGLWidget

After Qt 5.3′s introduction of QQuickWidget, Qt 5.4 adds QOpenGLWidget, the long-awaited replacement for the legacy QGLWidget. This widget retains the familiar initializeGL/resizeGL/paintGL API, while enabling full interoperability with other widgets in complex user interfaces.

Internally QOpenGLWidget is built on the same technology as QQuickWidget. Unlike QGLWidget, it is not a native window and will not turn any siblings or ancestors into native either. This avoids stacking, clipping, focus and performance issues and is expected to behave identically across all supported platforms.

Benefits for Embedded

QOpenGLWidget also brings the possiblity of having QWidget-based interfaces and one or more OpenGL widgets on embedded hardware without a windowing system, using the eglfs platform plugin. The dreaded EGLFS: OpenGL windows cannot be mixed with others error is now a thing of the past. It also helps Wayland. At the moment the Wayland platform plugin does not have subsurface support and so attempting to embed a QGLWidget or QWindow into a widget layout is futile: the result is always a standalone, separate window. With QOpenGLWidget this is not the case anymore.

Below is a photo of the qopenglwidget example running on an i.MX6 SABRE Lite board with Embedded Linux and Qt Enterprise Embedded:


The application might look familiar to some. This is in fact an enhanced port of the old hellogl_es2 example, which has never actually worked in Qt 5 with the eglfs platform plugin, due to using QGLWidget as a child widget, which leads to creating multiple native windows. By simply changing the base class from QGLWidget to QOpenGLWidget, the problem disappears, and the application behaves identically across all desktop, mobile and embedded devices.

Benefits for Desktop

Of course, it is not just for OpenGL ES. On desktop platforms, OpenGL 3.x and 4.x, including core profiles, are fully supported. Unlike QGLWidget, which forced the usage of legacy and often incomplete utility classes like QGLFormat and QGLContext, QOpenGLWidget uses the modern equivalents from the QtGui module: QSurfaceFormat, QOpenGLContext and the other, modern QOpenGL classes.

The basic API is same as in QGLWidget. For example, a simple subclass could look like the following:

class Widget : public QOpenGLWidget, protected QOpenGLFunctions
    Widget(QWidget *parent = 0);
    void initializeGL();
    void resizeGL(int w, int h);
    void paintGL();

    QMatrix4x4 m_projection;

Widget::Widget(QWidget *parent) : QOpenGLWidget(parent)
    QSurfaceFormat format;

void Widget::initializeGL()

void Widget::resizeGL(int w, int h)
    m_projection.perspective(60.0f, w / float(h), 0.01f, 1000.0f);

void Widget::paintGL()

This should look quite familiar to those who have used QGLWidget before.

The usage of QOpenGLFunctions is not mandatory on most platforms, but it is highly recommended for applications intended to be cross-platform and future-proof. Those who find the inheritance-based approach annoying, can always get a current context’s ready-to-be-used QOpenGLFunctions instance via QOpenGLContext::currentContext()->functions().

Advanced Topics

OpenGL 3.0+ and Core Profiles

Applications that are interested in modern OpenGL 3.x and 4.x features, can request a suitable context by setting the version, profile and possibly other settings in the QSurfaceFormat, just like they would do for a QWindow or QQuickView:

format.setVersion(4, 3);

However, with Qt 5.4 there is a better way: The newly introduced setDefaultFormat() member function of QSurfaceFormat. This static function can be called at a suitable early stage during application initialization. It will then apply to all contexts (QOpenGLContext) and OpenGL windows and widgets (QWindow, QOpenGLWindow, QQuickWindow, QOpenGLWidget, …) that are created afterwards. For example the following snippet ensures that all contexts request an OpenGL 4.3 core profile compatible context, and all windows request a depth and stencil buffer. The need for individual setFormat() calls for each and every context or window is thus eliminated:

    int main(int argc, char **argv)
        QApplication app(argc, argv);
        QSurfaceFormat format;
        format.setVersion(4, 3);

Context Sharing

Advanced scenarios that require multiple contexts, potentially for use on multiple threads, are simplified too. For example, to generate or upload textures on a worker thread, we can simply do something like:

    QOpenGLContext *context = new QOpenGLContext;
    QOpenGLContext *shareContext = openglWidget->context();

With this initialization done on the gui thread, our new context can be made current on the worker thread and the two contexts can access each others textures.

Desktop applications that use multiple OpenGL widgets, possibly inside multiple top-level windows, will often wish to share resources like textures between these widgets. This is made easy with QOpenGLWidget:

  • For QOpenGLWidget instances that are placed into the same top-level window, sharing is implicit and always enabled.
  • For QOpenGLWidget instances that are placed into different top-level windows, the new application attribute Qt::AA_ShareOpenGLContexts is provided. Setting this attribute at the beginning of the application will make the contexts of all QOpenGLWidget and QQuickWidget instances sharing with each other without any further steps. No more manual setting up of share hierarchies, as was the case with QGLWidget.


With a replacement for QGLWidget, the QtOpenGL module, that is the good old QGL classes, can finally be avoided in all types of Qt applications. Therefore, while QGLWidget and friends are not going to disappear overnight, they will be deprecated in Qt 5.4 and it is strongly recommended to avoid using them in new applications. Instead, go for QOpenGLWidget.

P.S. As mentioned in the QQuickWidget post, there is a limitation regarding semi-transparency when using QQuickWidget or QOpenGLWidget as child widgets. For applications that absolutely need this, Qt 5.4 offers a workaround: the newly introduced Qt::WA_AlwaysStackOnTop widget attribute. This, at the expense of breaking the stacking order for other types of layouts, makes it possible to have a semi-transparent QQuickWidget or QOpenGLWidget with other widgets visible underneath. Of course, if the intention is only to make other applications on the desktop visible underneath, then the Qt::WA_TranslucentBackground attribute is sufficient.

I Did it My Way

I flew to Bilbao on the 11th of August and took a train to Burgos. From there I walked 500km over 21 days to arrive in Santiago. Although technically a Catholic pilgrimage, I approached it secularly as a walking holiday, a different environment while in-between jobs and some time for myself. Everyone walks their own Camino.

First Insight: There is suffering

On arrival in Burgos, I needed to first get a ‘Credential’, which allows sleeping in the albergues for Peregrinos along the route, and records qualification to recieve a Compostela at the end of the journey. A credential may be obtained from the municipal albergue in Burgos so that was my first stop. It was almost 8pm when I arrived and the Hospitalero had been telling people since 4pm that the albergue was full. However, he kept a spare bed for such late arrivals and luckily he gave it to me. It made for a good start.

Many sunflowers on the Meseta

Many sunflowers on the Meseta

Stated in a deliberately impersonal way, the nature of suffering on the Camino was immediately apparent when I arrived in Burgos. For most people (with sufficient time), The Camino starts in St. Jean Pied de Port in France from where pilgrims walk over the Pyrenees, and through Pamplona before arriving in Burgos two weeks later. Colloqially, this first of three stages of the walk is known as the ‘Camino of Suffering’, where the pilgrim starts the challenge and experience. I spent the first evening with a few people who had developed the blisters and the tendonitis, people who were bidding farewell to the journey already (some people do it over multiple years), and people who were bidding farewell to companions.

In the morning I got up at 6am and started walking in the dark out of Burgos, following the centuries-old route along the second stage – the ‘Camino of Death’, so called because of the barren, flat landscape surroundings until reaching Astorga.

Initially I walked with one Italian guy and we soon caught up with two more Italians. Most of the time walking the Camino is spent walking alone though, so that little group quickly dissolved as people broke away or fell behind (ahem!). A social shock I experienced is that when someone in a group stops or slows (even one more-familiar than a few hours/days), the others simply continue on – they’re sure to be re-united at a break-point or end point later along the way. It’s something to get used to.

My shadow's the only one that walks beside me...

My shadow’s the only one that walks beside me… I have tonnes of photos like this. Depending on whether I like you, I might sit you down to show you all of them!

Second Insight: Suffering should be understood

One of the things I learned on the Camino is that ‘normal’ is partly an environmental concept. It became ‘normal’ for me to get up at 6am, walk 20-30km per day, eat with some strangers and some familiar faces and go to sleep at 10pm. It did take about a week for that to become ‘normal’ (and even enjoyable!), but it is certainly not similar to my Berlin experience.



I had blisters since the first day of walking, but by the time I reached Bercianos I was no longer able to stand, let alone walk. I had a day off followed by a 7km walk to the next town where I happened to meet a foot doctor from Berlin who gave me all the help I needed, including her sandals. My footwear was the problem causing my blisters (I was walking in running shoes), so I bought myself a good, expensive pair of sandals when I got to Leon, gave the good doctor hers back and had no new problems caused by footwear for the next two weeks. What are the odds of a foot doctor having the same size feet as me?

Chica the dog

Chica the dog

Most of the people I encountered on the Camino were Italians, Spanish a close second, and plenty of Germans. I fell into a good rhythm with a group of Germans for the second two weeks which was nice. We spoke German as our common language.


Third Insight: Suffering (of my Camino) has been understood

Astorga is a beautiful town and it marks the transition of the peregrino from the ‘Camino of Death’ into the ‘Camino of Life’. The route through Galicia is much more steep than the previous stages and full of the sights, sounds and smells of dairy farms. Most of the milk produced in Spain is produced here. The sunflowers filling the landscape and the trail are long since gone.

Although the blisters did not return, the steep climbs and descents brought with them some tendonitis for the final two days of walking. Not much to complain about, timing wise.

It’s sad that the experience of walking the Camino can’t be captured by any camera or prose, but must be experienced to be understood. That’s just part of the nature of suffering :).


Like many, I continued on to Finisterre for a few days of sleeping on the beach and unlike most I spent the weekend after in Barcelona, for a very different experience of parks and beaches.

Qt 5.4.0 Alpha is Out!

Representing a significant milestone towards the next Qt release, the alpha version of Qt 5.4.0 came out this week. Qt 5.4.0 will include a number of interesting new features. In this blog post, I will briefly mention just a few of the highlights.

QtWebEngine, the replacement for QtWebKit that I described in a blog post a few months ago, will be included in the Qt 5.4.0 release and will be supported on the following desktop platforms: Linux, Mac OS X and Windows.

Qt 5.4 Alpha Available

Qt 5.4 release process is ongoing and we now have the Qt 5.4 Alpha release available. As always, the Alpha is in source code only. Binary installers will be available in a few weeks with the Beta release. Features of Qt 5.4 are now frozen and in the next months the focus is in finalising and polishing functionality. To give an overview what is coming with Qt 5.4, I’ll summarise the highlights of the Qt 5.4 Alpha release.

WinRT fully supported

With Qt 5.4 we will have full support for Qt for WinRT. Based on the feedback and experience we have gotten from Qt 5.3 the WinRT port has been polished and improved. For Windows Phone deployments, we have set Windows Phone 8.1 as the minimum supported version, allowing us to remove the dependency on the previously-used D3D compiler service and greatly simplify deployment to the device. Most Qt modules are now supported on WinRT, so with Qt 5.4 it is easy to bring your Qt applications to Windows Phone, Windows tablets and PCs with the Modern UI, as well as publish in the Windows Store.

Graphics improvements

With QQuickWidget introduced in Qt 5.3 it became possible to easily show Qt Quick content inside a Qt widgets based application. Qt 5.4 introduces QOpenGLWidget, the modern replacement for the old QGLWidget class from Qt 4. QOpenGLWidget is a new widget for showing OpenGL rendered content, which can be used like any other QWidget. This also allows us to deprecate old Qt OpenGL module, as everything it does and more is now provided by other modules.

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

On Windows it is now possible to dynamically select during the application startup whether to use ANGLE or OpenGL. It is possible to use either opengl32.dll or ANGLE’s OpenGL ES 2.0 implementation in Qt applications without the need for two separate builds of the binaries.

Android Style for Qt Quick Controls

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

Qt Bluetooth and BluetoothLE

Qt Bluetooth now supports Bluez5. There is also a technology preview implementation of Bluetooth Low Energy available.

New Qt WebEngine and Qt WebChannel

The biggest new item Qt 5.4 brings is the new Qt WebEngine, integrating the comprehensive web capabilities of Chromium 37 into Qt. The integration with Qt focuses on an API that is easy to use, yet extensible. We have worked hard with the new Qt WebEngine ensuring seamless graphics integration, to allow rendering of Chromium’s textures directly into the OpenGL scene graph of Qt Quick. Earlier this year we have already released Qt WebEngine with Qt Enterprise Embedded, with Qt 5.4 we are now adding support for the desktop platforms Linux, Mac OS X and Windows.

In addition to Qt WebEngine, Qt 5.4 introduces new Qt WebChannel module for integration of QML/C++ and HTML/JavaScript. Qt WebChannel can be used to expose QObject functionality to Javascript in Qt WebKit or Qt WebEngine.

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

Other items

These are just a few examples of new things, you can find a more detailed list in wiki for what is new in Qt 5.4. If you try out Qt 5.4 Alpha, you may want to check the Known issues page.

Qt Location and Qt 3D have also been under work recently, but they are not ready to be included in Qt 5.4.

More licensing options

As a new licensing option, Qt 5.4 comes with LGPLv3 licensing option for all Qt modules, as announced earlier. The new Qt WebEngine is available only with LGPLv3 and GPLv2 licenses, as well as the commercial Qt Enterprise license. For more information about this change, please refer to the “Adding LGPLv3 to Qt” blog post.

Download Qt 5.4 Alpha

You can find Qt 5.4 Alpha source packages in your Qt Account, if you are a Qt Enterprise licensee, of from Qt Project Downloads, for the open-source version.

Join the Qt Fix and Polish Week

Originally we thought the title should be Qt Bug Fixing week, but that would have been too simple.
Here at Digia, we always work to deliver the best Qt releases that we can. We work to fix as many bugs as possible, while still progressing and implementing new features. We try to please everyone and get the balance right.
However, sometimes it’s important to focus. For the week of the 15th to the 22nd of September, we decided we’ll step away from other tasks and take a fresh look at some outstanding issues. We will focus on three areas:

  • Bugs
  • Examples
  • Auto Tests

Qt has a great community that likes to know what’s going on and get involved! Instead of only keeping our efforts behind closed doors, we invite everyone to participate. We will coordinate most of the work through IRC (we’ll start #qt-bugs on freenode) and hope to get many P1s out of the way for Qt 5.4.


People working in the Digia offices will team up and focus on these projects:


One thing we don’t do enough during normal development and bug fixing is actually taking a step back and looking at the bigger picture. We try to get an overview of the bug situation before each release, and hope to catch all issues that would be show stoppers, and prevent regressions as much as possible. This will be an early round for Qt 5.4.

In order to get an overview, we’ll create JIRA filters and share them to classify bugs and decide what’s important and where we need to focus our efforts. One improvement that we’ll be implementing is the closing of old issues, which was decided upon at the last Qt Contributors’ Summit in Berlin. After weeding out and agreeing on which bugs are most important for us to fix, we in Digia will focus on getting those bugs fixed. This is a great opportunity to start contributing to Qt by fixing your own pet peeve. We invite anyone to join, and will help them to get started fixing their highest priority issues.


We also have a long list of issues when it comes to examples. We will take out the magnifier and get the pixels aligned, make colors harmonize and finally ensure that more examples work well on all platforms. We have quite a few examples that work well on desktop, but not always so much on mobile platforms. If you have a keen eye for details, here’s your opportunity to join and help make Qt shine.

Auto Tests

We spend a lot of time getting the continuous integration system that Qt uses, to be in good shape. One thing that is frustrating to everyone contributing to Qt is that some tests are unreliable. We call them “flaky” because on a good day they’ll just work and everything is fine. But when they have a bad day and the moon is full they turn into real blockers. That can be caused by timing issues, relying on a certain order of things to happen or other obscure circumstances. We don’t like to admit it, but some tests for Qt are not optimal. If we spend time on cleaning up tests, we increase the general speed of getting patches into Qt which leads to a higher pace in development.

Time and Date

We’ll start Monday the 15th of September in the morning (Europe time) and announce the results on Monday 22nd of September. 

PyQt. How to shoot yourself in the foot.

Once upon a time there was a programming language called C. And it had 2 memory management functions: malloc() and free(). But it was too complicated.

Bjarne Stroustrup decided that C memory management should be easier. So he invented C++. In addition tomalloc() and free(), C++ had new, delete, destructors, RAII, auto and shared pointers.

Guido van Rossum found that C++ was also not simple enough. He chose another way and invented Python - a language which doesn't have even malloc() or free().

Meanwhile Norwegian trolls created the C++ GUI library Qt. It simplifies memory management by deleting objects automatically when it thinks the objects are not needed.

A man called Phil Thompson was upset that a cool library like Qt doesn't exist in the excellent Python language. He combined them in the PyQt project. But it is not so easy to combine different memory management paradigms. Let's see what the pitfalls are.

read more

Looking for Qt Champions!

Qt Champions are the individuals who go that extra mile and make Qt shine.

They welcome you, they help you, they’ll hunt and fix bugs, they’ll give tips on good coding, they write and make videos and they are there at conferences to tell people of Qt.

A Qt Champion is a recognized superhero of the Qt Community. You’ll be able to identify Qt Champions online and at Qt events.

Today, we are launching an initiative to recognize and celebrate our Qt Champions. They deserve to be noticed online and offline.

Nominations for Qt Champion titles are now open and we hope to have the first Qt Champion titles handed out at Qt Developer Days in Berlin!

Who do you think earns the title of Qt Champion?

Nominate your favorite heroes for a Qt Champion title!

Rock the Qt Shirt – Qt Developer Days 2014 Shirt

***Update: Happy to announce and excited to see you in the #QtDD14 shirt. Thanks to everyone who participated & congrats to Werner Rammer. ***


We want to tap into the amazing creativity of our community, and create shirts designed by YOU! Show us your talent & submit an original design for our 2014 Qt Developer Days T-shirt Design Contest to win a FREE conference pass!


For some inspiration, check out last year’s proposals.

• The design must be your own original, unpublished work and must not include any third-party logos or copyrighted material; by entering the competition, you agree that your submission is your own work.
• Design should be one that appeals to the majority of the Qt community.
• Design may include line art and text; no gradients or photographs.
• T-shirt color will be determined by the contest committee based on the winning design. You may specify a preference for a dark or light shirt color with your design entry.
• Your design is for the front of the shirt and may encompass an area up to 210 × 297mm (8.27 × 11.7 inch)
• Design may use a maximum of three colors (any of the solid colors of the Qt logo)
• All to say, simple is better.

Items the shirt must incorporate:
• Include the Qt logo

Items that could be included/incorporated:
• Location: Berlin / San Francisco (choose one)
• Conference Dates: Oct 6-8 / Nov 3-5 (choose one)

Qualifying Designs
• Maximum of three entries per person.
• High-resolution (300 dpi) layered .psd/.eps/.tif (Photoshop) file,  .ai/.eps Vector Files (Illustrator) or .pdf are preferred
• Do NOT send Microsoft Office files or Low- Resolution Files
• Email submissions to qt.info@digia.com Subject: Rock The Qt Shirt – Qt Developer Days 2014 Shirt
• Submissions will be accepted through Sunday, September 7 at 23:59 CEST / 14:59 PDT.
Note: If you have any questions about how to properly submit your file, please contact email questions to qt.info@digia.com Subject: T-Shirt Contest Help

The Fine Print
• Must be original art. Content found on the internet rarely has the resolution needed for print and is often considered unlawful to use without permission
• Submissions will be screened by the contest committee for merit and feasibility
• The contest committee reserves the right to make changes to the winning design before printing, including changes in image size or ink color
• By submitting your design, you grant permission for your design to be used by the Digia Qt Team including, but not limited to, the Qt website, the 2014 Qt Developer Days T-shirt, and future marketing materials
• The contest committee reserves the right to final decision

Here’s a tip for making your submission shine
To increase your chances to win share your design on your social media channels (Twitter and/or Facebook) using hashtag #QtDD14shirt and @qtproject during Sep 1 – Sep 7. Feel free to encourage your followers to share your post. The decision will be based mainly on your design’s popularity on Social Media.

The winning design will be announced Tue, September 9. The person behind the winning design will get a free two-day pass to Qt Developer Days in either Berlin or San Francisco.

Get your pencils sharpened or fire up your design software of choice, send us your sketches and flood the Social Media with your design(s)! We’re excited to see what you’ll come up with!

PS: Did you have a look at the Qt Developer Days 2014 agenda? Check it out and start planning your trip!

The KDE Randa 2014 meeting, in easy-digestible video format!

In case you were wondering what was going on in Randa, here are some first hand impressions. The video was produced by Françoise Wybrecht (alias Morgane Marquis) and Lucie Robin, and the people in it are the actual participants of the event. It was also created using KDenlive, one of the awesome Free Software tools a team has been working on at the Randa meeting itself. The video introduces the faces and personalities of the contributors and their different backgrounds and origins. Many thanks to our brand new ad-hoc media team for producing this video!

(In case the embedded video does not show up, see here: https://www.youtube.com/watch?v=yua6M9jqoEk)

Filed under: Coding, CreativeDestruction, English, FLOSS, KDE, OSS, Qt Tagged: Creative Destruction, FLOSS, free software communities, KDE

Qt Weekly #18: Static linking with Qt

Qt has supported static builds for a long time, but iOS made this way of shipping Qt more widespread. To make the discussion about static linking more practical, we will not discuss things abstractly, but we will look at how to compile the Weather Info example application from the Qt Positioning module statically for iOS, and address questions as they come up.


Weather Info example app

Weather Info example app

First of all, to build a static application, we need a statically compiled Qt. This is not difficult — adding the “-static” option to configure mostly does it. However, ensuring that the dependent libraries are also available and linked statically can take some effort. In the case of iOS, Qt is statically built by default, so we can simply use the default Qt packages.

To build the Weather Info application statically, let’s just try building as usual, running qmake and make (or even better, let Qt Creator call them for us).

cd weatherinfo
qmake -r weatherinfo.pro CONFIG+=debug

…and… it runs!

So, it seems that we don’t have to do anything special once we have a static Qt.
Great, so is this blog post already finished?

Well, not quite. If we take a look at the linking step, we see a huge command line (EDIR=/Users/fawzi/Qt5.3.1/Examples/Qt-5.3/positioning/weatherinfo):

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk -L$EDIR/Debug-iphoneos -L/Users/fawzi/Qt5.3.1/5.3/ios/plugins/platforms -L/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/System/Library/Frameworks -L/Users/fawzi/Qt5.3.1/5.3/ios/lib -L/Users/fawzi/Qt5.3.1/5.3/ios/qml/QtQuick.2 -L/Users/fawzi/Qt5.3.1/5.3/ios/plugins/accessible -L/Users/fawzi/Qt5.3.1/5.3/ios/plugins/qmltooling -L/Users/fawzi/Qt5.3.1/5.3/ios/plugins/position -L/Users/fawzi/Qt5.3.1/5.3/ios/plugins/bearer -L/Users/fawzi/Qt5.3.1/5.3/ios/plugins/imageformats -F$EDIR/Debug-iphoneos -filelist $EDIR/weatherinfo.build/Debug-iphoneos/weatherinfo.build/Objects-normal/armv7/weatherinfo.LinkFileList -dead_strip -headerpad_max_install_names -stdlib=libc++ -u _qt_registerPlatformPlugin -L/Users/fawzi/Qt5.3.1/5.3/ios/plugins/platforms -framework UIKit -L/Users/fawzi/Qt5.3.1/5.3/ios/lib -framework OpenGLES -L/Users/fawzi/Qt5.3.1/5.3/ios/qml/QtQuick.2 -L/Users/fawzi/Qt5.3.1/5.3/ios/plugins/accessible -L/Users/fawzi/Qt5.3.1/5.3/ios/plugins/qmltooling -L/Users/fawzi/Qt5.3.1/5.3/ios/plugins/position -L/Users/fawzi/Qt5.3.1/5.3/ios/plugins/bearer -L/Users/fawzi/Qt5.3.1/5.3/ios/plugins/imageformats -lz -lm -miphoneos-version-min=5.0 -lqios_debug -framework Foundation -framework QuartzCore -framework CoreFoundation -framework CoreText -framework CoreGraphics -lQt5PlatformSupport_debug -framework Security -framework SystemConfiguration -lqtquick2plugin_debug -lqtaccessiblequick_debug -lqmldbg_qtquick2_debug -lQt5Quick_debug -lqmldbg_tcp_debug -lQt5Qml_debug -lqtposition_cl_debug -framework CoreLocation -lqtposition_positionpoll_debug -lQt5Positioning_debug -lqgenericbearer_debug -lQt5Network_debug -lqdds_debug -lqicns_debug -lqico_debug -lqjp2_debug -lqmng_debug -lqtga_debug -lqtiff_debug -lqwbmp_debug -lqwebp_debug -lQt5Gui_debug -lqtharfbuzzng_debug -lQt5Core_debug -Xlinker -dependency_info -Xlinker $EDIR/weatherinfo.build/Debug-iphoneos/weatherinfo.build/Objects-normal/armv7/weatherinfo_dependency_info.dat -o $EDIR/Debug-iphoneos/weatherinfo.app/weatherinfo

It looks mostly OK, but contains a lot of libraries. System and Qt libraries are expected, but we also have:

  • the platform plugin:-lqios_debug that loads plugins/platforms/libqios_debug.a
  • the QtQuick2 plugin:-lqtquick2plugin_debug that loads qml/QtQuick.2/libqtquick2plugin_debug.a
  • the accessibility plugin for qtquick:-lqtaccessiblequick_debug that loads accessible/libqtaccessiblequick_debug.a
  • the plugin to improve debugging of qtquick2:-lqmldbg_qtquick2_debug that loads plugins/qmltooling/libqmldbg_qtquick2_debug.a
  • the plugin to talk to the QML debugger:-lqmldbg_tcp_debug that loads plugins/qmltooling/libqmldbg_tcp_debug.a
  • the plugin giving the position using the core location framework: -lqtposition_cl_debug that loads plugins/position/libqtposition_cl_debug.a
  • the generic polling plugin for position:-lqtposition_positionpoll_debug that loads plugins/position/libqtposition_positionpoll_debug.a
  • the plugin giving the generic bearer implementation: -lqgenericbearer_debug that loads plugins/bearer/libqgenericbearer_debug.a
  • support for the DDS image format:-lqdds_debug that loads plugins/imageformats/libqdds_debug.a
  • support for the ICNS image format:-lqicns_debug that loads plugins/imageformats/libicns_debug.a
  • support for the ICO image format:-lqico_debug that loads plugins/imageformats/libqico_debug.a
  • support for the JPEG 2 image format:-lqjp2_debug that loads plugins/imageformats/libqjp2_debug.a
  • support for the MNG image format:-lqmng_debug that loads plugins/imageformats/libqmng_debug.a
  • support for the TGA image format:-lqtga_debug that loads plugins/imageformats/libqtga_debug.a
  • support for the TIFF image format:-lqtiff_debug that loads plugins/imageformats/libqtiff_debug.a
  • support for the Wireless Application Protocol Bitmap image format:-lqwbmp_debug that loads plugins/imageformats/libqwbmp_debug.a
  • support for the WebP image format:-lqwebp_debug that loads plugins/imageformats/libqwebp_debug.a

The platform plugin and a couple of others should come as no surprise, but Wireless Application Protocol Bitmap? A format by WAP for black and white images? When WAP has basically disappeared? Does our application really need it?

While, the non-debug version libqwbmp.a is only around 15 KB in size, things like libqjp2.a can be around 600 KB, so this is definitely worth some investigation.

One could hope that unneeded code gets stripped away. After all, that is one of the advantages of static linking which leads to a smaller executable than shipping all dynamically loaded libraries. If a function in a library is not used, that function is not part of the static executable.

Unfortunately, plugins make the situation more complex.

Qt Plugins

Qt internally uses dynamic linking in several places, mainly with plugins. Plugins are used for platform dependent support, image formats, audio and video codecs, sensors, and so on.

If you take a look in the plugin directory (qmake -query QT_INSTALL_PLUGINS) you will see the various plugins that Qt might use.

For example, linking QtPositioning, and QtMultimedia is not enough to have a position fix and being able to display a movie, respectively. The required plugins also need to be loaded.

Calling the Q_IMPORT_PLUGIN marcro from user code will load that plugin (which will thus need to be linked).

When using dynamic linking, the plugins are loaded automatically at runtime when needed.
With static linking, one has to decide which plugins are required already at build time.

Starting with Qt 5.3, thanks to Ossi, a meaningful set of plugins (depending on the Qt modules you added) is automatically loaded.
That is the reason why without any extra effort things just worked in the above example, but that is also the reason we have so many plugins linked to our executable.

qmake does not just add the -l<plugin> to the link flags (which has no effect if not used), but really uses the plugin.
Indeed, if we look at the linked files from $EDIR/weatherinfo.build/Debug-iphoneos/weatherinfo.build/Objects-normal/armv7/weatherinfo.LinkFileList:


we see weatherinfo_plugin_import.o which comes from the compilation of the autogenerated
$EDIR/weatherinfo_plugin_import.cpp which contains the Q_IMPORT_PLUGIN that takes care of loading the Qt plugins.

This is nice, but we want a lean application, without unnecessary cruft, so how can we get rid of the plugins we do not need?

As described in How to Create Qt Plugins, it is possible to switch off the automatic loading of plugins with CONFIG -= import_plugins, but this disables the generation of the weatherinfo_plugin_import.cpp file, and then we would have to do everything manually: add Q_IMPORT_PLUGIN somewhere in our code, define the QT_STATICPLUGIN preprocessor variable and link the plugin (as one has to do without qmake).

We just want to specify which plugin to load, but still leave the ugly details up to qmake.
How to Create Qt Plugins also states that one can set the list of plugins to load for each class with QTPLUGIN.<className>. The position plugins we will actually need, but the image conversions? We should be able to get rid of all of them.

So let’s add


to our project file, weatherapp.pro, and indeed no more image formats plugins are linked, the release executable becomes around 1MB smaller (13’492’384 -> 12’539’088 bytes), avoids unneeded plugins initializations, and… still works.

If some imageformat plugins are needed, it is possible to add them to QTPLUGIN.imageformats, or directly to QTPLUGIN.

It is worth noting that for this to work, the plugin creator has to define both PLUGIN_TYPE and PLUGIN_CLASS_NAME to make the automatic loading work. There were some issues with that, but hopefully all have been fixed.

QML Plugins

Our example basically uses just QtQuick 2, but in general one has to scan recursively the imports of all QML files used to find all plugins to load, and to load them. Morten wrote a tool that scans the QML files (qmlimportscanner) and qmake uses it to generate $EDIR/weatherinfo_qml_plugin_import.cpp which gets compiled to the weatherinfo_qml_plugin_import.o file we have previously seen in the linked files.

For this to work, the QML files have to be found by the tool (which might for example require installing Qt in some cases) and the qmldir files have to specify the classname of the plugin.


Static linking avoids the dependency on external libraries and leads to smaller packages for a single self-contained application (all the unused code of a library is stripped).
But for the linker, “used code” means code that might be reached, and to make plugins work, one has to pull in the plugin using Q_IMPORT_PLUGIN and link it.

qmake simplifies this operation by generating special files and linking the modules, but its default choices about which modules your application wants to use are not always correct. Furthermore, reachable code does not necessarily mean code that will be executed, or that does something useful for your application. For example, the initialization of a plugin might be a bit expensive, so doing it unconditionally at startup is not always a good idea.

Thus removing plugins that are not needed is a good way to make your application leaner.
There are also other places where Qt might waste CPU time (to initialize things) or space (both in application size and memory), as for example the MIME DB or Unicode information, but that is another story…

It is important to note that static linking has consequences with respect to the licenses of Qt you might want to use. While you are probably safe if your application is distributed according to the terms of a recognized free and open-source license, you should definitely check the licensing issue for proprietary or closed-source applications. Qt Enterprise license is the recommended one for closed-source applications.

I hope this has made the issue and advantages of static linking with Qt clearer. Happy coding and let me know if you have comments or tips.

qbs 1.3.0 released

We are happy to announce the release of qbs 1.3.0 today. Qbs, or Qt Build Suite, is a general cross-platform build tool that uses a language similar to QML for project description. Qbs can be used for any software project, whether it is written in Qt or not and it simplifies the build process for developing projects across multiple platforms.

If you haven’t tried it out yet, we strongly encourage you to take it for a spin to see how convenient building with Qbs is! Check out the documentation for more details.

What’s new in qbs 1.3?

For this release, we have concentrated on improving the integration with Qt Creator. The main points are:

  • Source files can now be added to (and removed from) qbs products via the project tree, just as for qmake projects. Thanks to Thomas Epting for the initiative!
  • More care is now taken to reload a project only if it is really necessary.
  • In addition, reloading a project has become somewhat faster, particularly in the case where a project file was changed without introducing any semantic differences (e.g. whitespace changes).

We think that these items, combined with a number of important bugfixes, have improved the user experience of working with qbs in Qt Creator a lot.

What else is worth mentioning?

On the language side, it is now possible to set different profiles for particular products. This is important for projects that need to produce binaries for different architectures.
Also, we have once again reduced the memory footprint significantly.

Where do I get it?

Source packages and a binary package for Windows can be found here.
Qt license holders can download the enterprise version of qbs directly from their Qt Account.

Other relevant links

Wiki: http://qt-project.org/wiki/qbs
Documentation: http://qt-project.org/doc/qbs-1.3/index.html
Bug tracker: https://bugreports.qt-project.org/browse/QBS
Mailing list: http://lists.qt-project.org/mailman/listinfo/qbs

Alternatives for Virtual Keyboards

With touchscreen-based systems such as tablets, smart phones and embedded devices, there is often a need for a virtual or on-screen keyboard. Qt itself does not provide a virtual keyboard and I am often asked for recommendations on approaches for a virtual keyboard. I thought this would make a good topic for a short blog post. Let's look at some of the options available.

How to contribute to the KDE Frameworks Cookbook

The annual KDE Randa Meeting, in itself already shock-ful of awesome, this year hosted the KDE Frameworks Cookbook sprint. Valorie, Cornelius and I already wrote a lot about it. Plenty of attention went into finding the place for the cookbook between the getting-started HOWTOs on KDE Techbase and the full-blown API documentation. Not surprisingly, there is a space and a good purpose for the book. Frameworks developers and maintainer have had to deal with the question of where to put introductions that segue newcomers into how to use the modules many times, and so far, the answer have been unsatisfactory. Newcomers only find the API documentation when they already know about a framework, and TechBase is a great resource for developers, but not necessarily a good introduction. What is missing is a good way to help and learn about what KDE Frameworks have to offer. So there is the purpose of the KDE Frameworks Cookbook – to help developers find and learn about the right tools for the problems they need to solve (and also, consumable on a e-book reader by the pool). For developers and maintainers, this means they need to know how to add sections to the book that cover this information about their frameworks. These tools and workflows will be explained in this post.

Im a way, the book will partly provide an alternative way to consume the content provided by KDE TechBase. Because of that, the HTML version of the book will integrate and cross-link with TechBase. The preferences of what kind of documentation should be in the book or on TechBase are not yet written in stone, and will probably develop over time. The beauty of Free Software is that it also does not matter much – the content is there and may be mixed and remixed as needed.

Two principles have been applied when setting up the tooling for the KDE Framworks Cookbook. The first is that content should stay in the individual frameworks repositories as much as possible. The second is that content taken from the frameworks, like code snippets, shall not be duplicated into the book, but rather referenced and extracted at build time.

KDE Frameworks Cookbook front cover

Keeping content that is part of the book in the frameworks repositories makes it easier for developers and maintainers to contribute to it. A book can grow to ginormous proportions, and keeping track of where its text is related to a specific framework or piece of code will be difficult if the two are separated into different places. However, content that is not specific to individual frameworks may as well be placed in the book repository. Considering that contributions of code and prose are voluntary and compete for the available time of the people working on it, it is important to keep the workflow simple, straightforward and integrated with that of development. Frameworks authors add sections to the book by placing Markdown formatted texts in the framework’s repository. The repository for the book (kde:kf5book) references the frameworks repositories that provide content as Git submodules, and defines the order in which the content is included using a CMake based build system. The target formats of the book, currently PDF, HTML and ePub, are generated using pandoc. Pandoc can also be used by the contributors to preview the text they have written and check it for correct formatting. The book repository already contains various sections pulled in from the frameworks repositories this ways. Interested contributors will probably find it easiest to follow the existing examples for the submodule setup and the build instructions in the CMakeLists.txt file to add their content. The ThreadWeaver repository (kde:threadweaver) contains Markdown files that are part of the cookbook in it’s examples/ folder which can serve as a reference. See below for why the file names end in .in.md.

Avoiding duplication by copy-pasting code into the book is achieved by using a special markup for code snippets and other examples and a separate tool to extract them. Especially example and unit test code that is shown in the book should always be part of the regular, CI tested build of the respective framework. This ensures that all code samples shown in the book actually compile and hopefully work for the reader. The snippetextractor tool processes the input files that only contain references to the code samples and produces complete Markdown files that include the samples verbatim. The input file names end in .in.md. The conversion of the input files is handled by the build system of the kf5book repository, not in the individual frameworks repositories. It is however possible to add steps to produce the final Markdown files to the CMake build files of the repository. This will catch markup errors of snippets during the frameworks build, but does require the snippetextractor tool to be installed.

Setting up continuous builds for the book target formats is currently being worked on. Producing the book will be integrated into KDE’s Jenkins CI, and up-to-date version of it will be available on KDE TechBase. Until then, curious readers can self-produce the book:

  • Install pandoc and the necessary Latex packages to produce PDF output.
  • Build and install snippetextractor using QMake and a recent (>5.2) Qt. Make sure it is in the path before running CMake in the later steps.
  • Clone kde:kf5book, and initialize the Git submodules as described in the README file.
  • In a build directory, run cmake <source directory> and make to produce the book.

Enjoy reading!

Filed under: Coding, CreativeDestruction, English, FLOSS, KDE, OSS, Qt Tagged: Akademy, FLOSS, free software communities, KDE, kde community

How syntax highlighting works

This article was written 1 year ago. I finally found the time to translate it to English

If you are a programmer, you spend a significant amount of your time coding. It doesn’t matter how many buttons or menus or IDE or editor has, the core is a code editor component. Do you know how it works?
This article explains how syntax highlighting in Qutepart (and katepart) works. The article is not about UI, but about the architecture. If you are interested, lets go..

read more