• Shortcuts : 'n' next unread feed - 'p' previous unread feed • Styles : 1 2

» Publishers, Monetize your RSS feeds with FeedShow:  More infos  (Show/Hide Ads)

Date: Thursday, 13 Sep 2012 12:05

Today’s blogger and presenter of Qt 4.8.3 is Tuukka Turunen, Director Qt R&D at Digia.

Most of the activities have lately been around Qt 5, but rest assured – Qt 4.8 is still very much alive as well! I am extremely pleased to announce that we have released 4.8.3 today together with the Qt Project. Since the previous release there are over 200 fixes and improvements included to the 4.8.3 making it worthwhile to migrate into for most 4.8 users.

Highlights of 4.8.3 include changes to better support Mac OS X 10.8 and QNX, as well as new WebKit (2.2.3). With over 200 improvements there are many really important ones to talk about, but for now lets just say that there are a lot of other improvements, for example to QtCore, QtGui and QtNetwork modules.

A detailed list of the fixes and improvements, as well as a change log showing differences from Qt 4.8.2 can be found here.

As agreed with the Qt Project, Digia has packaged and tested Qt 4.8.3, which feeds from the Qt Project 4.8 branch. We will keep providing patch releases to 4.8 as long as needed. Currently we believe that at least two more patch releases will be needed. Qt 5 provides high compatibility with Qt 4 and we recommend Qt users to migrate their active projects to Qt 5.0 after the final version release is available.

We have tagged the Qt 4.8.3 release in the Qt Project repository. The source packages and stand-alone installers for Qt 4.8.3 are available for download at http://qt-project.org/downloads. For commercial licensees there is also online SDK update available. For more details, please see qt.digia.com.

We look forward to your feedback and hope you use the Qt Project mailing lists to keep the conversation going.

Author: "tuukka" Tags: "Qt"
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 11 Sep 2012 09:54

This prerelease of Qt Creator 2.6 gives you a an early impression of the many new features and the bigger changes that we will introduce with this release. And of course it is your chance to give us last feedback and help us find bugs and problems :)

Let’s start with the most apparent change: We replaced what we called “Target” before in Qt Creator, with what we call “Kits”.

“Targets” were basically a setting for something related to the device type, e.g. “Desktop”, “MeeGo Device” and so on. They were fixed, hardwired into Qt Creator, and came with defaults for build settings like which tool chain and debugger and sysroot to use. Some settings were unclear how they were chosen (like the Qt version). Some combinations of settings were prevented, for example the available tool chains were reduced to the ones Qt Creator thought would work with the Qt version you chose. You’d add support for a “target” to your project in Projects mode, and build and run settings were set up with the defaults. Deviating from the defaults required manually changing all build and run configurations.

“Kits” basically specify which combinations of device, compiler, debugger, and Qt version (and possibly other settings) you want to develop for. They are user defined, and the set of options in the kits is extensible from (binary) plugins. You define kits through adding them in Tools > Options > Build & Run > Kits, where you then freely choose each individual settings value in the kit independent from all others (meaning that you can for example choose any compiler that you configured in Tools > Options > Build & Run > Compilers, independent from what Qt version you set). If Qt Creator thinks that a certain combination of settings will not work, it prints a warning, but it does not prevent you from knowing better ;) . You add support for a kit to your project in Projects mode similar to it was before with “targets”. You can change a kit to use different settings, and any change is automatically reflected on all projects that use that kit. Qt Creator sets up a default kit on first run, with settings derived from the tools found in your PATH.


Regarding new features, we merged both the Android support and the QNX support into Qt Creator 2.6. This is great news on the “platform support” side of things, and even more impressive because we did all the above mentioned refactoring regarding targets and kits simultaneously. Thanks to all that made this happen!

These new supported target platforms are unfortunately shadowed a bit by the fact that we also had to drop Symbian support because of missing maintainer.

New are also experimental support for Gerrit, which allows you to browse your current changes and browse the diffs or cherry-pick/pull directly from within Qt Creator, and experimental support for the ClearCase version control system. There have been lots of other smaller and larger changes and fixes, like compilation of single files for qmake projects, more fixes for C++11, and a UI for setting temporary breakpoints, just to name a few. You find the more complete changes list here.

All in all 75 people have contributed to this release (see the end of the changes file), a big Thank You to all of them!

Get binaries and source code from our download page.

Note to Mac OS X Mountain Lion users: The application is not signed yet, to open it you need to right click and select “Open” from the context menu the first time you run it.

Note to Windows and Linux users: We are currently in the process of moving the package build infrastructure to the Qt Project. Unfortunately we cannot offer you installers for this release, simply uncompress the 7z files and run the Qt Creator binary located in the bin/ directory.

Author: "Eike Ziller" Tags: "Qt, QtCreator"
Comments Send by mail Print  Save  Delicious 
Date: Friday, 07 Sep 2012 09:52

It’s been now some days since we released the Qt 5 beta, and thus it is time to look ahead to what’s going to happen in the next few months and the plans for the Qt 5.0.0 final version release.

Moving to Digia

The first important thing is that the planned transfer of Qt from Nokia to Digia is anticipated to be finalized in Q3. I personally have also chosen to join Digia and continue my work on Qt from there. Having now had quite a few talks with Digia, I believe this is going to be a great opportunity both for Qt and for the development teams in Oslo and Berlin.

From all I can see, Digia has a solid, long-term strategy with Qt, focusing strongly on the product, pushing for Qt 5 and making Qt the best possible development tool out there. This is a large acquisition for Digia, which underlines how strategic they believe Qt will be for them in the future.

Digia wants to grow the Qt ecosystem together with other players in the market. They understand the importance of keeping that ecosystem unified. They also understand how important dual licensing is for the Qt ecosystem.

The teams planned to transfer from Nokia will be a significant addition to the business unit that is currently selling Qt Commercial. The people coming from Nokia are, to a large extent, developers and the former Nokia teams will actually form the majority of the development team in Digia.

Of course, there will be changes for the Nokia Qt people joining Digia, but I do believe that they will be changes for the better. These changes will include a broader focus on customer needs and a more immediate feedback cycle from our customers to development. This is something I’m personally looking forward to.

But some things are planned to stay the same. We aim to continue the strong focus on product development and pushing the boundaries of what can be done with Qt. Qt 5 is planned to be be the central focus of most of our work, both short and longer term.

Finalizing the Qt 5.0 release

One of the most important things to do in the short term now is to finalize Qt 5. The Qt 5 beta has now added binary packages for the main platforms, but it is still missing some pieces. We are aiming at including Qt Creator into the Qt 5.0 release and creating a package that is similar to the Qt SDK packages we have released for 4.x.

We had a workshop on Monday in Oslo trying to identify the work that remains to be done. Apart from general bug fixing a couple of items clearly showed up, and we will strongly focus on these for the next couple of weeks:

  • Documentation

    While the individual class documentation is in an OK state, lots of work remains to be done to tie it all together. We are lacking overview documentation, intros to Qt and the different modules, some getting started help and a good landing page. Making the difference between Qt Essentials and Add-ons clear, as well as cross-referencing between modules still requires work. We have now a team in Oslo that will focus on putting all of this in place.

  • Examples and Demos

    A lot of the existing examples in Qt have been there for a long time. We will go through the list and do a cleanup of the examples, probably removing a large part of them in the process and focusing on having a small but high quality set of examples available for Qt 5.0.

  • Finishing and testing our reference platforms

    This is mainly bug fixing and testing, but nevertheless extremely important. On some platforms we will need to do some more work than on others.

    On Windows, we will change the default build to use ANGLE (OpenGL on top of DirectX) to avoid issues with bad OpenGL drivers and remote desktop. In addition this will make the Multimedia and WebKit integration easier and with improved performance. Of course, building against the regular desktop OpenGL drivers will still be supported.

    On Mac and Linux, there’s also work required to finish the multimedia integration as well as many other smaller issues.

    WebKit 2 and the QML module for WebKit have been disabled for the beta. The WebKit team is now very close to having this work on all reference platforms.

  • Qt Creator

    We are aiming at adding Qt Creator to the binary packages. The Berlin team will focus on making sure Qt Creator will work as smoothly as possible together with Qt 5.

  • Packaging

    Finally, we need to pull all the pieces together into a decent set of packages. What we have seen from the beta is that one can easily underestimate that part of the work, so we will need to have some extra focus in this area.

I would like to aim for a second beta as soon as possible, but only once most of the issues mentioned above are resolved. A realistic time frame for this second beta release is probably in around 4-6 weeks from now. After that we will quickly push for a release candidate and a Qt 5.0 final release.

Longer term

As soon as the team has moved to Digia, and we start having some time again in parallel to finishing Qt 5, we plan to focusing also on new things. Digia has already publicly communicated some areas they consider important, such as an Android and iOS support. In addition, the teams in Berlin and Oslo have been coming up with many good ideas.

We are now in the process of sorting through these ideas and prioritizing them. Our goal is to be as open and transparent as we can be about what we will be doing, as well as what we’re not going to do. In this way, we aim to avoid duplicating work and give everybody the chance to participate in the Qt Project.

Author: "Lars Knoll" Tags: "Qt"
Comments Send by mail Print  Save  Delicious 
Date: Wednesday, 05 Sep 2012 10:17

So, we have the Qt 5 beta out! The next steps now are to polish it to make the Qt 5.0.0 release as impressive as possible.

One big, pending task we’ve identified is making sure the class reference documentation is consistent with the changes we’ve made in Qt 5. Since this was originally written when widgets were the only way to do GUIs in Qt, some of the documentation is rather widget-centric in how it presents things. There might also be other content in there that is no longer correct, or less relevant, with the changes made in Qt 5.

The only way to fix this is really to go through the classes manually. We need to actually read the documentation for each class to make sure it still makes sense and presents Qt in a way that give people the information they need to make good decisions. If it is somehow unclear or seems stuck in the past, we need to update it with something better.

One example of such an update was in the QSyntaxHighlighter docs, where the description of the class referred to a constructor which had been removed in Qt 5, when the class was made independent of widgets. This reference was simply removed. Another example was the QTextDocument docs, which have been rephrased a little to identify the class as a general rich text layout engine, and not only as the back-end for QTextEdit, which is just one isolated use case in the context of Qt 5. Note, though, that for the majority of classes, there will not be any issues, but we won’t know for sure until someone’s read the documentation and verified it.

If you’ve been looking to get into developing on the Qt Project, this might be good time to get started. It’s definitely a very useful way to get familiar with the different parts of Qt and the infrastructure around it, and the patches you’ll be making are simple and low risk.

To organize the work, we’ve made a wiki-page. If you want to help out, please edit the page and replace “unassigned” with your name next to the class you’re claiming to avoid duplicate work. If the class requires patching, please make sure the change is actually merged before you mark the class as “done”.

To get started with Qt development, go to the Qt Project homepage and look at the guides posted there. You might also have use for the QDoc reference documentation to figure out what all the magic tags are for.

Finally, just ask if you have any questions. We really appreciate any help we can get with this!

Author: "Eskil Abrahamsen Blomfeldt" Tags: "C++, Contributors, Qt"
Comments Send by mail Print  Save  Delicious 
Date: Thursday, 30 Aug 2012 11:20

The Qt 5 Beta is now available as the first major release under the new Qt Project umbrella. A big thank you goes out to all who contributed to this milestone. With this Qt 5 beta release, I would also like to invite everybody interested to go, try, and experience this next major version of Qt. Your feedback now will be very important in making the final release of Qt 5.0 as good as possible.

It’s now 15 months since we announced the start of Qt 5 development, and I am really happy to see what has been achieved during this time. All of the major architectural changes that we planned for have been implemented. At the same time, the community around Qt and qt-project.org has seen a nice and healthy growth.

Qt 5 will make it easier and faster to create:

  • Smooth, accelerated graphics performance with limited resources. Qt 5 makes better use of the GPU to deliver better performance on inexpensive hardware. For example, using Qt 5 you can achieve 60 fps performance on a $35 single-board computer like Raspberry Pi. – See the Qt on Pi project for more info.
  • Advanced UIs and applications written in QML and JavaScript. See the Qt Media Hub as an example
  • Powerful apps connected to the web

High-performance Apps and UIs

Qt 5 addresses two core challenges developers face when creating high-performance apps and UIs:

  1. Better tools to design the UIs and
  2. Better rendering performance to execute your vision.

The new extensions and APIs to the QML language make it easier to create rich and fluid apps and UIs for touch screen devices in addition to supporting keyboard input methods. Qt 5′s updated WebKit and Qt Quick modules support out-of-the-box touch interaction for smooth user experiences.

The new graphics stack sports an all-new rendering pipeline using an OpenGL based scene graph that is fully optimized for Qt Quick. This makes it trivial to integrate OpenGL-based content, such as shader effects or particles. Text rendering is also fully hardware accelerated, giving you faster graphics and lower power consumption. As a result, Qt 5 delivers the same 60 fps smoothness seen on high-end smartphones even when executed on inexpensive hardware like the Raspberry Pi.

Providing Source Compatibility and Continuity – Porting and QWidgets

A lot of effort has gone into making the transition of your code base and skill set from Qt 4 to Qt 5 as easy as possible and to keep as much source compatibility with Qt 4.x as we can. As an example we currently have Qt Creator compiling and running against Qt 4.x and Qt 5 using the same code base.

You can find links to detailed porting instructions on the Qt 5 beta page or look at some examples of KDAB’s porting efforts.

Updating your code base is primarily a process of updating your projects’ .pro files, to change header file includes and add used modules. Qt 5 provides a script that facilitates this task. In addition, code that integrates with native windowing system functionality of the underlying platform will need some adjustments.

While new UI designs benefit from the updated QML for mobile and embedded applications, it is also important to notice that existing widget-based designs remain viable. Widget-related APIs continue; QWidget and all derived classes are a core part of Qt 5 on the Desktop – and will remain so.

New APIs and modules

In addition to the changes to the internal architecture, a lot of new APIs have also found their way into Qt 5. Many new classes appeared in QtCore, providing support for JSON, mimetype recognition, standard paths and many other things.

The OpenGL support is now an integral part of QtGui and has received some nice improvements. QWindow provides a better abstraction for top-level windows then the old QWidget.

A couple of new modules have been added to the scope of Qt 5. In particular, the differentiation between Qt and Qt Mobility that existed in Qt 4.x has been removed. Instead we now have a more modular structure and each module (a shared library or QML import) is now classified as either being part of the Qt Essentials or an add-on.

This new structure will make it easier in the future to integrate modules providing new functionality into the Qt Product offering, and allow for example KDE to provide their frameworks as add-ons to Qt.

Greater opportunity

In addition to delivering the best development environment possible, it is important that Qt increases your opportunity to get your projects in front of a bigger audience.

With Qt 5, support for multiple operating systems continues. The QPA abstraction layer makes the task of porting to new platforms easier and more seamless then ever before. We are already seeing a lot of work going into Qt 5 to implement a full port to QNX and Blackberry 10. Digia has already announced their plans to port Qt 5 to Android and iOS.

In addition, a lot of effort and contributions have gone into especially improving the use case for embedded developments on Linux. This helped the strong growth/up-take we witnessed within Qt for Automotive, IPTV/ STB and other IP comms manufacturers for current and next gen infotainment systems.
Discussions regarding what additional improvements Qt 5.1 will bring to the desktop use case and how quickly i.e. we can integrate Qt desktop components are ongoing and were also part of the sessions that ran during 3 days when close to 200 contributors attended the Qt Contributor Summit in Berlin during the end of June.

Known issues

While we are happy with the current state of the beta in most places, there are a few known issues that you might want to check out from our Known-Issues page. Most notably, you will need decent OpenGL drivers on Windows for Qt Quick to work, and there are issues remaining with Qt Multimedia on platforms other than Linux.

We expect these issues to get resolved for the Qt 5.0 final, where we will by default use ANGLE to layer OpenGL on top of DirectX (the option to use the native OpenGL support on Windows remains of course) and work on the remaining Multimedia issues.


One thing that is becoming very visible now is how much the start of the Qt Project and move to Open Governance helped in improving Qt. Over the last year, we have managed to create a very active and passionate community of developers around Qt, and many of the improvements we are now seeing in Qt 5 would not have been possible without all this efforts.

As an example, I’d like to mention all the improvements that flowed from the KDE libraries back into Qt 5. These will actually make it possible to have a more modular approach for KDE applications and fully remove the differentiation between a KDE and a Qt app

I am very proud of what has been achieved with Qt 5. A big thank you goes to everybody who has in some way contributed to bringing Qt 5 to where it is now. Let’s also take a bit of time to celebrate all the hard work that has gone into this release, as the first major beta released under the new Qt Project umbrella.

Lars Knoll

Author: "Lars Knoll" Tags: "Qt"
Comments Send by mail Print  Save  Delicious 
Date: Monday, 20 Aug 2012 14:03

One of the shortcomings of the Qt Quick API is that despite having a dedicated rendering thread, our animations are always running on the GUI thread.

Running animations outside the application’s main thread has the advantage that it greatly reduces jerkyness as operations that block the main thread will not hinder the animations from running.

There are three primary problems hindering us:

  • Animations update properties and these are tied to QObjects and the meta object system. To avoid threading insanity, we can only read and write these on the GUI thread.
  • Properties often have bindings in QML, which trigger JavaScript execution which must happen on the GUI thread.
  • The threaded render loop in the QtQuick library is driven by the GUI thread and does not redraw unless told, so if the GUI is blocked, nothing updates.

As I mentioned in my previous post, the render loop in the “customcontext” in ssh://codereview.qt-project.org:29418/playground/scenegraph.git fixes the third problem, but that leaves the issue of access to QObjects and JavaScript execution.

A colleague of mine, Marko Niemelä, has been working on an animation system that solves the QObject / QML binding part. His work is in the “animators” directory of the playground repository.

This is not Qt 5.0 material, but maybe we can get it in good shape for 5.1.


Author: "Gunnar Sletta" Tags: "Performance, Qt Quick 2"
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 14 Aug 2012 14:50

For robustness and security reasons, it often makes sense to split functionality into various smaller binaries (daemons) rather than having a few big and monolithic applications.

Qt 4 introduced modularized Qt libraries in order to enable Qt based daemons that don’t require any GUI. Thanks to the strong embedded focus and several sane architecture decisions, Qt 5 brings this to a new level.

Let’s look at some simple main function:

QCoreApplication app(argc, argv);
QTimer::singleShot(3000, &app, SLOT(quit()));
return app.exec();

This non-gui Qt app idles for about 3 seconds, then quits.

On my vanilla i386 Kubuntu 12.04 with Qt 4.8.1, valgrind’s massif tool reports a peak heap memory usage of around 102 kb, while callgrind reports an instruction cost of about 1.9 million (*).

Let’s have a look at the numbers from today’s build of Qt 5: Massif reports a peak heap of 4.9 kb and callgrind reports an instruction cost of about 114k.

This means that Qt 5 uses about 20 times less memory and about 16 times less instructions to construct a QCoreApplication and spin an event loop.

There are several reasons for that. Most notably, Qt 5 assumes that all strings are unicode, so the initialization of text conversion codecs only happens when the first non-unicode string comes along. Even though Qt 5 has vastly improved plugin loading performance, not loading them is even faster :)

Various other improvements also add up, e.g. the C++11 support in Qt 5 means that we require no allocation to create unicode QString objects and moving objects around also got cheaper.

In summary, have fun writing Qt 5 based daemons, and if you have any idea how to make the code even more performant, we’ll see you at Qt’s codereview :)

(*) Disclaimer: The instruction cost does not show how fast the code is, but how many instructions were processed by the CPU. Note that in all cases I only measured the performance of main(), ignoring the overhead of the OS’s symbol and library resolving, as that can be optimized with prelinking or forking from a master process.

Author: "Harald Fernengel" Tags: "Performance, Qt"
Comments Send by mail Print  Save  Delicious 
Date: Thursday, 09 Aug 2012 12:29

Qt Creator 2.5.2 contains only a single bugfix that is important to all Windows (7) users:

  • Fixed resource leak leading to regular crashes on Windows (QTCREATORBUG-7385)

So, if you are a Windows user of Qt Creator, I advise you to quickly go to our download page to get the new version. Everyone else can safely ignore this release.

Author: "Eike Ziller" Tags: "Qt, QtCreator"
Comments Send by mail Print  Save  Delicious 
Date: Wednesday, 08 Aug 2012 12:41

One of the comments in Morten’s blog post about desktop components in QML 2 was that the text looks out of place on Windows. This is because QML 2 uses a custom rendering mechanism called “distance fields” for the text which allows hardware accelerated drawing of transformable text. Yoann blogged about this a year back.

This is what the distance field text looks like in the desktop components:

Qt 5 desktop components rendered with distance field text

Qt 5 desktop components rendered with distance field text

While distance field text is perfect for UI components for which you want smooth animated movement, rotations and zooms, it will look different from the text rendered by native applications on Windows. This is especially true because the distance field text renderer does not apply grid-fitting hints to the glyphs, whereas this is the standard on Windows. Note that on e.g. Mac OS X, the standard is to draw the text without applying grid-fitting, so the distance field text will not look as out-of-place on this platform.

Grid-fitting means that the shapes of the glyphs are modified for the current font size and device resolution in order to make them look sharper. This is done by moving control points around e.g. to avoid features of the glyph being positioned between two pixels, which would cause the anti-aliasing to fill both those pixels, partially blending the font color with the current background in order to give the visual impression that the glyph touches half of each pixel. A sharper image can be made if the feature fills exactly one full pixel instead. The mechanism is especially effective for low pixel densities and small font sizes.

The downside of grid-fitting, in addition to certain typographical consequences, is that the text and its layout becomes unzoomable. This is because the modifications to the glyphs happen based on the target size of the glyph on screen. When you scale it, the shapes of the glyphs will change, making the shapes wobble, and the metrics of the text will also change, requiring a relayout of the text. If you zoom on a web page, for instance, the paragraph you wanted to see up close might have moved around significantly by the time you get to a text size you can comfortably read, and then you will have to pan around to find it again.

When using distance fields, we will render the glyphs without grid-fitting to make them scalable. An additional convenience of this is that we only have to cache the shape of each glyph once, whereas grid-fitted glyphs have to be cached per size. This saves some memory and also makes effects like animated zooms a lot faster, since the glyphs can be redrawn at every zoom level using the same distance field cache.

Here’s what the previous screen shot looks like if you scale the push button by a factor of two:

Distance field rendered text with zoomed button

Distance field rendered text with zoomed button

But while the distance fields have many advantages, they don’t cover the need to have applications that look like they belong together with other Windows applications. For an application using desktop components, you can imagine this being a more important goal than having smoothly transformable text items. On a desktop machine running Windows, the memory cost of a glyph cache might not be the primary concern either. I’ve been meaning to fix this for a while. The code for drawing text through the system back-end instead of the distance field renderer has been in the scene graph since the text nodes were originally written, but so far there has not been any convenient way for developers to choose it over the default. With change 6a16f63df4a51edee03556f841d34aad573870f2 to Qt Declarative, this option has now been added. On any text component in QML, you can now set the renderType property to NativeRendering in order to use the system back-end to rasterize the glyphs instead of Qt. This will apply to any platform, although it will have the largest effect on Windows or on Linux when hinting is turned on in the system settings.

Text {
    text: "Some text"
    renderType: Text.NativeRendering

I’ve added the branch qt5-nativetext to the desktop components repository where the effect can be tested. The components in this branch will use the distance field renderer by default, but by setting the DESKTOPCOMPONENTS_USE_NATIVE_TEXT environment variable to “1″, you will be able to see the difference. Running qmlscene on Gallery.qml with this environment variable set yields the following result:

QML 2 widgets with native-looking text

QML 2 widgets with native-looking text

So the appearance is crisper and the text fits in on the platform, but scaling the text does not give the nice results we had before, and will instead look pixelated. See the following screen shot for comparison:

The effect of zooming native-looking text

The effect of zooming native-looking text

So the choice is yours. If you’re targeting Windows and you want your application to look like a standard, native Windows application, you can use the renderType property to achieve this. If you want the lean, flexible and transformable text of Qt, leave the property unaltered.

Author: "Eskil Abrahamsen Blomfeldt" Tags: "Qt, Qt Quick, Qt Quick 2, Qt Quick 2.0, ..."
Comments Send by mail Print  Save  Delicious 
Date: Wednesday, 01 Aug 2012 10:43

Both the public documentation for the scene graph and some of my previous posts on the subject have spoken of a backend or adaptation API which makes it possible to adapt the scene graph to various hardware. This is an undocumented plugin API which will remain undocumented, but I try to go through it here, so others know where to start and what to look for. This post is more about the concepts and the ideas that we have tried to solve than the actual code as I believe that the code and the API will most likely change over time, but the problems we are trying to solve and the ideas on how solve them will remain.

Some of these things will probably make their way into the default Qt Quick 2.0 implementation as the code matures and the APIs stabilize, but for now they have been developed in a separate repo to freely play around with ideas while not destabilizing the overall Qt project.

The code is available in the customcontext directory of ssh://codereview.qt-project.org:29418/playground/scenegraph.git


When we started the scene graph project roughly two years ago, one of the things we wanted to enable was to make sure we could make optimal use of the underlying hardware. For instance, based on how the hardware worked and which features it supports, we would traverse the graph differently and organize the OpenGL draw calls accordingly. The part of the scene graph that is responsible for how the graph gets turned into OpenGL calls is the renderer, so being able to replace it would be crucial.

One idea we had early on was to have a default renderer in the source tree that would be good for most use cases, and which would serve as a baseline for other implementations. Today this is the QSGDefaultRenderer. Other renderers would then copy this code, subclass it or completely replace it (by reimplementing QSGRenderer instead) depending on how the hardware worked.

Example. On my MacBook Pro at the time (Nvidia 8600M GT), I found that if I did the following:

  1. Clear to transparent,
  2. render all objects with some opaque pixels front to back with blending disabled, while doing “discard” on any non-opaque pixel in the fragment shader, but writing the stacking order to the z-buffer,
  3. then render all objects with translucency again with z-testing enabled, this time without the discard,

I got a significant speedup for scenes with a lot of overlapping elements, as the time spent blending was greatly reduced and a wast amount of pixels could be ignored during the fragment processing. Now, in the end, it turned out (perhaps not surprising) that “discard” in the fragment shader on both the Tegra and the SGX is a performance killer, so even though this would have been a good solution for my mac book, it would not have been a good solution for the embedded hardware (which was overall goal at the time).

On other hardware we have seen that the overhead of each individual glDrawXxx call is quite significant, so there the strategy has been to try to find different geometries that should be rendered with the same material and batch them together while still maintaining the visual stacking order. This is the approach taken by the “overlap renderer” in the playground repository. Cudos to Glenn Watson in the Brisbane office for the implementation.

Some other things that the overlap renderer does is that it has some compile-time options that can be used to speed things up:

  • Geometry sorting – based on materials, QSGGeometryNodes are sorted and batched together so that state changes during the rendering are minimal and also draw calls are kept low. Take for instance a list with background, icon and text. The list is drawn with 3 draw calls, regardless of how many items there are in it.
  • glMapBuffer – By letting the driver allocate the vertex buffer for us, we potentially remove one vertex buffer allocation when we want to move our geometry from the scene graph geometry to the GPU. glVertexAttribPointer (which is all we have on stock OpenGL ES 2.0) mandates that the driver takes a deep copy, which is more costly.
  • Half-floats – The renderer does CPU-side vertex transformation and transfers the vertex data to the GPU in half-floats to reduce the memory bandwidth. Since the vertex data is already in device space when transferred, the loss of precision can be neglected.
  • Neon assembly – to speed up the CPU-side vertex transformation for ARM.

If you are curious about this, then I would really want to see us being able to detect the parts of a scene graph that is completely unchanged for a longer period of time and store that geometry completely in the GPU as vertex buffer objects (VBO) to remove the vertex transfer all together. I hereby dare you to solve that nut :)

And if you have hardware with different performance profiles, or if you know how to code directly in the language of the GPU, then the possibility is there to implement a custom renderer to make QML fly even better.

Texture implementation

The default implementation of textures in the QtQuick 2.0 library is rather straightforward. It uses an OpenGL texture with the GL_RGBA format. If supported, it tries to use the GL_BGRA format, which saves us one RGBA to BGRA conversion. The GL_BGRA format is available on desktop GL, but is often not available on embedded graphics hardware. In addition to the conversion which takes time, we also make use of the glTexImage2D function to upload the texture data, which again takes a deep copy of the bits which takes time.

Faster pixel transfer

The scene graph adaptation makes it possible to customize how the default textures, used by the Image and BorderImage elements, are created and managed. This opens up for things like:

  • On Mac OS X, we can make use of the “GL_APPLE_client_storage” extension which tells the driver that OpenGL does not need to store a CPU-side copy of the pixel data. This effectively makes glTexImage2D a no-op and the copying of pixels from the CPU side to the GPU happens as an asynchronous DMA transfer. The only requirement is that the app (scene graph in this case) needs to retain the pixel bits until the frame is rendered. As the scene graph is already retained this solves itself. The scene graph actually had this implemented some time ago, but as I didn’t want to maintain a lot of stuff while the API was constantly changing, it got removed. I hope to bring it back at some point :)
  • On X11, we can make use of the GLX_EXT_texture_from_pixmap where available and feasible to directly map a QImage to an XPixmap and then map the XPixmap to a texture. On a shared memory architecture, this can (depending on the rest of the graphics stack) result in zero-copy textures. A potential hurdle here is that XPixmap bits need to be in linear form while GPUs tend to prefer a hardware specific non-linear layout of the pixels, so this might result in slower rendering times.
  • Use of hardware specific EGLImage based extensions to directly convert pixel bits into textures. This also has the benefit that the EGLImage (as it is thread unaware) can be prepared completely in QML’s image decoding thread. Mapping it to OpenGL later will then have zero impact on the rendering.
  • Pixel buffer objects can also be used to speed up the transfer where available

Texture Atlas

Another thing the texture customization opens up for is the use of texture atlases. The QSGTexture class has some virtual functions which allows it to map to a sub-region of a texture rather than the whole texture and the internal consumers of textures respect these sub-regions. The scene graph adaptation in the playground repo implements a texture atlas so that only one texture id can be used for all icons and image resources. If we combine this with the “overlap renderer” which can batch multiple geometries with identical material state together, it means that most Image and BorderImage elements in QML will point to the same texture and will therefore have the same material state.

Implementation of QML elements

The renderer can tweak and change the geometry it is given, but in some cases, more aggressive changes are needed for a certain hardware. For instance, when we wrote the scene graph, we started out with using vertex coloring for rectangle nodes. This had the benefit that we could represent both gradients, solid fills and the rectangle outline using the same material. However, on the N900 and the N9 (which we used at the time) the performance dropped significantly when we added a “varying lowp vec4″ to the fragment shader. So we figured that for this hardware we would want to use textures for the color tables instead.

When looking at desktops and newer embedded graphics chips, vertex coloring adds no penalty and is the favorable approach, and also what we use in the code today, but the ability to adapt the implementation is there. Also, if we consider batching possibilities in the renderer, then using vertex coloring means we no longer store color information in the material and all rectangles, regardless of fill style or border can be batched together.

The adaptation also allows customization of glyph nodes, and currently has the option of choosing between distance fields based glyph rendering (supports sub pixel positioning, scaling and free transformation) and the traditional bitmap based glyph rendering (similar to what QPainter uses). This can then also be used to hook into system glyph caches, should these exist.

Animation Driver

The animation driver is an implementation of QAnimationDriver which hooks into the QAbstractAnimation based system in QtCore. The reason for doing this is to be able to more closely tie animations to the screen’s vertical blank. In Qt 4, the animation system is fully driven by a QTimer which by defaults ticks every 16 milliseconds. Since we know that desktop and mobile displays usually update at 60 Hz these days, this might sound ok, but as has been pointed out before, this is not really the case. The problem with timer based animations is that they will drift compared to the actual vertical blank and the result is either:

  • The animation advances faster than the screen updates leading to the animation occasionally running twice before a frame is presented. The visual result is that the animation jumps ahead in time, which is very unpleasant on the eyes.
  • The animation advances slower than the screen updates leading to the animation occasionally not running before a frame is presented. The visual result is that the animation stops for a frame, which again is very unpleasant on the eyes.
  • One might be extremely lucky and the two could line up perfectly, and if they did that is great. However, if you are constantly animating, you would need very high accuracy for a drift to not occur over time. In addition, the vertical blank delta tends to vary slightly over time depending on factors like temperature, so chances are that even if we get lucky, it will not last.

I try to illustrate:

Timer-driven animations

The image tries to illustrate how advancing animations based on timers alone will almost certainly result in non-smooth animation

The scene graph took an alternative approach to this by introducing the animation driver, which instead of using a timer, introduces an explicit QAnimationDriver::advance() which allows exact control over when the animation is advanced. The threaded renderer we currently use on Mac and EGLFS (and other plugins that specify BufferQueueing and ThreadedOpenGL as capabilities), uses the animation driver to tick exactly once, and only once, per frame. For a long time, I was very happy with this approach, but there is one problem still remaining…

Even though animations are advanced once per frame, they are still advanced based to the current clock time, when the animation is run. This leads to very subtle errors, which are in many cases not visible, but if we keep in mind that both QML loaders, event processing and timers are fired on the same thread as the animations it should be easy to see that the clock time can vary greatly from frame to frame. This can result in a that an object that should move 10 pixels per frame could move for instance 8, 12, 7 and 13 pixels over 4 frames. As the frames are still presented to screen at the fixed intervals of the vertical blank, this means that every time we present a new frame, the speed will seem different. Typically this happens in the case of flicking a ListView, where every time a new delegate is created on screen, that animation advance is delayed by a few milliseconds causing the following frame feel like it skips a bit, even though the rendering performance is perfect.

I try to illustrate:

Animations using predictive times vs clock times

Animations using predictive times vs clock times

So some time ago, we added a “time” argument to QAnimationDriver::advance(), allowing the driver to predict when the frame would be presented to screen and thus advance it accordingly. The result is that even though the animations are advanced at the wrong clock time, they are calculated for the time they get displayed, resulting in is velvet motion.

A simple solution to the problem of advancing with a fixed time would be to increment the time with a fixed delta regardless, and Qt also implements this option already. This is doable by setting


in the environment. However, the problem with this approach is that there are frames that take more than the vsync delta to render. This can be because it has loads of content to show, because it hooks in some GL underlay that renders a complex scene, because a large texture needed to be uploaded, a shader needed to be compiled or a number of other scenarios. Some applications manage to avoid this, but on the framework level, recovery in this situation needs to be handled in a graceful manner. So in the case of the frame rendering taking too much time, we need to adapt, otherwise we slow down the animation. For most applications on a desktop system, one would get away with skipping a frame and then continuing a little bit delayed, but if every frame takes long to render then animations will simply not work.

So the perfect solution is a hybrid. Something that advances with a fixed interval while at the same time keeps track of the exact time when frames get to screen and adapts when the two are out of sync. This requires a very accurate vsync delta though, which is why it is not implemented in any of our standard plugins, and why this logic is pluggable via the adaptation layer. (The animation driver in the playground repo implements this based on QScreen::refreshRate()). So that on a given hardware, you can get the right values and to do the right thing.

And last, despite all the “right” things that Qt may or may not do, this still requires support from the underlying system. Both the OpenGL driver and the windowing system may impose their own buffering schemes and delays which may turn our velvet into sandpaper. We’ve come to distinguish between:

  • Non blocking – This leads to low latency with tearing and uneven animation, but you can render as fast as possible and current time is as good as anything. In fact, since nothing is throttling your rendering, you probably want to drive the animation based on a timer as you would otherwise be spinning at 100% CPU (a problem Qt 5.0 has had on several setups over the last year). Qt 5.0 on linux and windows currently assumes this mode of rendering as it is the most common default setting from the driver side.
  • Double buffered w/blocking swap – This leads to fairly good results and for a long time I believe this was the holy grail for driving animations. Event processing typically happens just after we return from the swap and as long as we advance animations once per frame, they end up being advanced with current clock time with an almost fixed delta, which is usually good enough. However, because you need to fully prepare one buffer and present it before you can start the next you have only one vsync interval to do both animations, GL calls AND let the chip render the frame. The threaded renderloop makes it possible to at least do animations while the chip is rendering (CPU blocked inside swapBuffers), but it is still cutting it a bit short.
  • 3 or more buffers w/blocking – Combined with predictive animation delta and adaptive catch-up for slow frames, this gives perfect results. This has the added benefit that if the rendering is faster than the vsync delta, we can prepare queue up ready frames. Having a queue of prepared frames means we are much more tolerant towards single frames being slow and we can usually survive a couple of frames that take long to render, as long as the average rendering time is less than the vsync delta. Down side of this approach is that it increases touch latency.

So, we did not manage to come up with a perfect catch-all solution, but the scene graph does offer hooks to make sure that a UI stack on a given platform can make the best possible call and implement the solution that works best there.

Render Loop

The implementation inside the library contains two different render loops, one called QQuickRenderThreadSingleContextWindowManager and another one called QQuickTrivialWindowManager. These rather long and strange names have grown out of the need to support multiple windows using the QtQuick.Window module, and was named window manager for that reason, but what they really are are render loops. They control when and how the scene graph does its rendering, how the OpenGL context is managed and when animations should run.

The QQuickRenderThreadSingleContextWindowManager (what a mouthful) advances animations on the GUI thread while all rendering and other OpenGL related activities happen on the rendering thread. The QQuickTrivialWindowManager does everything on the GUI thread as we did face a number of problems with using a dedicated render thread, particularly on X11. Via the adaptation layer, it is possible to completely rewrite the render loop to fit a given system.

One problem that QML has not solved is that all animations must happen on the GUI thread. The scene graph has no problems updating it self in another thread, for instance using the QSGNode::preprocess() function, but QObject based bindings need to have sane threading behavior, so these need to happen on the GUI thread. So as a result, the threaded render loop is at the mercy of the GUI thread and it’s ability to stay responsive. Guaranteeing execution on the GUI every couple of milliseconds is hard to do, so jerky animations are still very much possible. The traditional approach to this has been that we promote the use of threading from the GUI thread to offload heavy operations, but as soon as an application reaches a certain complexity having all things forked off to other threads, including semi-complex JavaScript, becomes hard and at times unbearable, so having some enablers available allowing that certain elements to animate despite what goes on in the application’s main thread is very much needed.

To remedy this, I started playing with the idea that the GUI thread would rather be a slave of the render thread and that some animations could run in the render loop. The render loop in the playground repo implements the enablers for this in the render loop, opening for a potential animation system to run there regardless of how the GUI thread is running.


There are a lot of ideas here and a lot of work still to be done, and much of this does not “just work” as Qt normally does. Partially this is because we have been very focused on the embedded side of things recently, but also because graphics is hard and making the most of some hardware requires tweaks on many levels. The good news is that this API makes it at least possible to harness some of the ability on the lower levels when they are available, and it is all transparent to the application programmer writing QML and C++ using the public APIs.

Thank you for reading!

Author: "Gunnar Sletta" Tags: "Performance, Qt Quick 2.0"
Comments Send by mail Print  Save  Delicious 
Date: Wednesday, 25 Jul 2012 12:22

We have released Qt Creator 2.5.1 today. It is a pure bugfix release which mends some of the more serious issues in the 2.5.0 release, including

  • fix in Qt for text editor font rendering on Mac, which would lead to incomplete rendering updates when not using the standard font
    (if you build Qt Creator yourself you’ll want to either use the Qt 4.8 branch or cherry-pick 5ac8e6ef178678f500668d67fe38d149f0821029)
  • fix for C++ template class completion issues
  • various other fixes

See the changelog for more details.

Binaries are on our download page.

Author: "Eike Ziller" Tags: "Qt, QtCreator"
Comments Send by mail Print  Save  Delicious 
Date: Friday, 20 Jul 2012 03:56

Here in sunny Brisvegas, ‘stralia, we have been doing more than not wearing shoes all year, we have been working all kinds of hard on QtDeclarative, QtMultimedia, QtLocation, QtSystems and QtSensors… oh ya, can’t forget Quality Assurance/CI System.

Of course, the most exciting one of these is QSensorGestures

With QtDeclarative, Qt3d, QtMultimedia and QtSensorGestures, you can have an awesome cross platform gaming platform with massive potential. Crikey Mate, That one is a ripper!

Apparently a hot topic for console games, tablets and mobile devices (as well as robots)  is – gesture recognition. Since I work in the Qt Sensors team, I decided to investigate gesture recognition using sensors such as accelerometer but also incorporating the light and proximity sensors and share with the world of Qt.

There are heaps of research papers detailing gesture recognition out there. Mostly using an advanced approach and algorithms which need a large amount of training data and time to teach the software the gestures. These systems are usually complicated and very detailed about the gestures they can support.

The Qt Sensors library in Qt 5 was developed as part of Qt Mobility. The Qt Sensor Gesture API was developed subsequently after the sensors code was integrated into the Qt 5 development branch.

Qt’s Sensor Gestures uses a plugin system for recognizer integration. Which means if the system allows installing plugins, you can write your very own recognizers. You could even go so far as to use the more complicated and popular way of writing gesture recognizers that use machine learning and computer vision techniques.

I have developed a few simple gesture recognizers in the QtSensorGesture plugin – pickup, twist, cover, hover, whip, turnover, shake and slam. This plugin uses an ad-hoc method of detecting gestures, but recognizer plugin can also use more advanced methods as well. This has the advantage of speed, memory usage and removing the lengthy process of machine training, but it has the disadvantage of the user not being able to create their own gestures, and recognizer collisions – where one gesture will be recognized when another gets performed. But that is always a hazard with sensor gestures.

These gestures are documented here (until the Qt5 release, anyway):


The current state of QSensorGestures is that the current plugins are most likely device specific, which means they might have to be adapted to any real hardware that might want to use them.

In the future, as well as adding “attributes/properties” for device specific configuration, there could be QtSensor backends for certain game controllers which have accelerometers as well as a library to access them, as well as other devices. I have also been looking into using the image sensors as well as audio sensors for gesture recognition, which would require more advanced methods of gesture detection.

I don’t have any flashy cool videos as I had hoped for, so you all will have to do with words, documentation and a few images.

and of course, the source code is available in the Qt5 repo.

Qt 5 is looking to be the best version of Qt yet!



Author: "Lorn Potter" Tags: "Gesture Recognizers, Qt, Qt Sensors, QtM..."
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 17 Jul 2012 04:16

The QML core team down under gained a new friend for Qt 5. We finally have the privilege of working with a designer in our team and he’s been helping us in our quest to make QML the most designer friendly UI language. We have created a small video to show you the latest apps and games from our team. But remember that videos aren’t the main point of Qt demos, the source code for these demos is all available from qt-project.org and it’s BSD licensed. I’ll even sprinkle links throughout this post to show the code behind all the new features that have me excited.

First have a look at our new calculator demo, Calqlatr, which has been restyled like the other demos. From its humble few hundred LoC beginnings, SameGame is also looking like a real application now. The new particle effects look even better, and you have your choice of four game modes. This includes a mode that loads preset levels, also written in QML.

QML demos are really easy to modify and play with; SameGame selects a new theme per game mode already, so you can try out your own samegame designs with ease. We also have a new game, “Maroon in Trouble”, with an underwater theme inspired by the rich life at the Great Barrier Reef. The game is highly customizable with the towers implemented in QML, both for their appearance and their gameplay attributes.

When you watched the video of “Maroon in Trouble”, you’ll notice that it avails itself of some of the new visual embellishments available in QtQuick 2. The particle system allows for bubbles and clouds to float all over the screen, while the new sprite elements made the game piece animations trivial to implement. As a bonus, the game has sound effects if you have the QtMultimedia module installed – a benefit of the modularization work in Qt 5.

The new visual effects aren’t just for games though. The completely redesigned twitter search app, TweetSearch, uses sprites and shaders for much more subtle designs. The central logo has a touch of animation to keep the main screen from being static, and the rotating bars use a custom ShaderEffect to get that three dimensional look (although you could use the Qt3D module instead). It also uses view transitions to populate in a more fluid fashion.

If you still can’t get the beautiful effects you want with all these new visual elements, QtQuick 2 also introduces the Canvas element for imperative painting. Especially good for graphing data, see it in action with the new StocQt stock chart viewer example.

The QML core team is really proud of how well QtQuick 2 has developed. This is especially true since modules from the other Brisbane teams, like the team behind QtMultimedia, are finally inside Qt after the modularization efforts. I hope that our demos help launch other developers to write even better games and apps.

Author: "Alan Alpert" Tags: "Qt Quick 2.0, demos, QML, qt quick"
Comments Send by mail Print  Save  Delicious 
Date: Friday, 22 Jun 2012 12:30

There are changes to the meta object-system in Qt 5, both under the hood and on the API side. Some of the changes are source incompatible with Qt 4. In this blog I’ll describe those changes and how to adapt existing code. I’ll also show a few small API additions that make it easier to work with QMetaMethods.

Removing support for Qt 4 meta-object versions

The meta-object data (e.g., as created by moc) has a version number that describes the contents (format/layout) and features of the meta-object. Whenever we add a new feature to the meta-object (such as making a class’s constructors introspectable) in a new Qt (minor) release, we must also increase the meta-object version. The “last generation” Qt 4 meta-objects have version 6.

To maintain backward compatibility, new minor versions of Qt have to support the meta-objects of previous versions. That’s achieved by checking the version of the individual meta-object at relevant places inside Qt, and falling back to an alternate codepath if the meta-object is of old age.

Since Qt 5 breaks binary compatibility with Qt 4 anyway, we took the opportunity to get rid of the support for old meta-object versions. The fallbacks would effectively be dead code in Qt 5, since Qt would never create a meta-object with a “Qt 4″ version. Qt 5 meta-objects currently have version 7.

moc output from Qt 4 does not compile with Qt 5. In (the hopefully rare) case your codebase contains some hand-edited moc output (which Qt itself does in a few places, to implement “special” meta-objects), you’ll have to recreate the moc output.

The various runtime meta-object builders in Qt (QMetaObjectBuilder, QtDBus, ActiveQt) have also been updated to generate version 7 meta-objects; since these are internal, existing code shouldn’t be affected. (Hopefully nobody out there wrote their own meta-object builder… :) )

Methods are no longer identified by strings

Prior to Qt 5, the meta-object contained the full, normalized signatures of the class’s signals, slots and Q_INVOKABLE methods, stored verbatim as zero-terminated strings. This probably made sense back when QObject::connect() was fully string-based (using the SIGNAL() and SLOT() macros). But now that there’s a template-based QObject::connect(), storing the full signature is a less obvious choice. (Dealing with signature strings internally was always necessary in Qt 4 due to the QObject::connectNotify() function; more on that in the next section.)

Another common use case of method introspection is dynamic bindings (QML, QtScript), where the normalized signature is, again, not an ideal representation to work with. The implementation would be simpler and more efficient if it had direct access to a method’s name and parameter types (no runtime parsing of strings required).

Lo and behold: In Qt 5, QMetaMethod has new functions name(), parameterCount(), and parameterType(int index). The full method signature is no longer stored verbatim in the meta-object data (only the method name is), since a compatible signature can be constructed on demand from the other bits of information.

Unfortunately, the existing QMetaMethod::signature() function returns a const char pointer; this leaked the fact that the signature used to be stored verbatim. We couldn’t simply change the return type to QByteArray, since implicit casting would cause existing code like the following to break without warning:

// If signature() returns a QByteArray, it would go out of scope (and be destroyed) after this statement:
const char *sig = someMethod.signature();
// Do something with sig and watch bad stuff happen, probably ...

To resolve this, we’ve introduced a new function in Qt 5, QMetaMethod::methodSignature(). The old QMetaMethod::signature() function is no longer available; calls to it will trigger a compiler error stating that signature() has been renamed. Existing code should be ported to use QMetaMethod::methodSignature(). Even with new functions like QMetaMethod::name(), obtaining the full method signature can still be useful in some cases, e.g. for debugging.

connectNotify() and disconnectNotify()

QObject::connectNotify() and disconnectNotify() are two rarely-reimplemented virtual functions that you can use to do something when someone connects to or disconnects from one of your class’s signals. One potential use is to implement lazy proxy (relaying) connections from some internal (“back-end”) object to the public signals. The qtsystems module does that heavily, for example.

Prior to Qt 5, connectNotify() was biased towards the string-based QObject::connect(), in that it received a const char pointer to a normalized signature that identified the signal that was connected to. For the template-based QObject::connect(), and for custom connections done in e.g. QML or QtScript, making Qt prepare a string representation of the signal just to call a virtual function that’s usually not reimplemented is sub-optimal.

Furthermore, the char pointer-based connectNotify() feels … un-Qt-ish. Even if you managed to spell the normalized form of the signature, you could still fall into the following trap (it happened inside Qt, even):

void MyClass::connectNotify(const char *signal)
    if (signal == SIGNAL(mySignal())) {
        // This will never get reached; comparing pointers, not strings ...

The documentation says you should wrap the signal argument in a QLatin1String, but it’s easy to forget to do so. The solution is to provide an API that doesn’t allow for such mistakes.

In Qt 5, QObject::connectNotify() and disconnectNotify() receive a QMetaMethod instead of a char pointer. A QMetaMethod is just a thin wrapper around a QMetaObject pointer and an index. It’s not biased towards any particular way a connection is established.

This change also allowed us to move the calls to connectNotify() and disconnectNotify() to the implementation of the internal index-based connect() and disconnect() functions (QMetaObject::connect(), which is used several places in Qt). In practice, this means that your connectNotify() reimplementation will get called as you would expect, even if QObject::connect() isn’t called explicitly (connectSlotsByName(), for example). Finally, we could get rid of some blush-inducing code in Qt that manually called connectNotify(const char *) in conjunction with the index-based connect().

Existing code that reimplements connectNotify() and disconnectNotify() needs to be ported to the new API. There are two new functions that should make it relatively easy: QMetaMethod::fromSignal() and QObject::isSignalConnected().


The new static function QMetaMethod::fromSignal() takes a member function (a signal) as argument and returns the corresponding QMetaMethod. It nicely complements the new connectNotify():

void MyClass::connectNotify(const QMetaMethod &signal)
    if (signal == QMetaMethod::fromSignal(&MyClass::mySignal)) {
        // Someone connected to mySignal ...

To avoid doing a specific signal lookup every time connectNotify() is called, you could keep the result of QMetaMethod::fromSignal() in a static variable.

Another obscure usage of fromSignal() is to perform a queued emission of a signal (QMetaObject::invokeMethod() would also do the trick, but it’s string-based):

    .invoke(myObject, Qt::QueuedConnection /* and arguments, if any ... */);


The new function QObject::isSignalConnected() can be used to check whether anything is connected to a signal. It’s a QMetaMethod-based alternative to QObject::receivers().

void MyClass::disconnectNotify(const QMetaMethod &signal)
    if (signal == QMetaMethod::fromSignal(&MyClass::mySignal)) {
        // Someone disconnected from mySignal
        if (!isSignalConnected(signal)) {
            // No more connections to this signal; we can release some resources now, perhaps ...

Alternatively, you can use this function to avoid emitting a signal altogether, e.g. if the emit would require some complex computations that could notably affect application performance.

QTBUG-4844: QObject::disconnectNotify() is not called when receiver is destroyed

UPDATE: Fixed by https://codereview.qt-project.org/#change,29423

This bug is currently still present, unfortunately. It’s a deficiency that effectively renders disconnectNotify() “incomplete” (or “broken”, depending on how you see it), so I’d really like to see the issue resolved.

To be able to implement the desired behavior efficiently, the connections would have to remember the signal id, since, when the receiver is destroyed, we cannot derive the signal id as we can in a normal (explicit) disconnect. This would add size overhead (one int) for all connections. If you can come up with a clever solution, there’s still time to get it into 5.0 (it’s likely too big of a behavior change to fix in a future minor release).

Method return type

Prior to Qt 5, you had to use QMetaMethod::typeName() to determine a method’s return type, in const char pointer form. Quirkily, typeName() returned an empty string if the return type was void — not the string “void”, as QMetaType::typeName() does. This inconsistency led to confusion; I’ve seen code that does

if (!method.typeName() || !*method.typeName() || !strcmp(method.typeName(), "void")) {
    // The return type is void ...

… just to be sure.

In Qt 5, you can use the new function QMetaMethod::returnType() instead, which returns a meta-type id:

if (method.returnType() == QMetaType::Void) {
    // The return type is void ...

In Qt 4, you couldn’t use QMetaType::Void to distinguish between void and unregistered types (they were both represented as the integer 0). In Qt 5, QMetaType::Void actually means the type void; the new value QMetaType::UnknownType is used to specify a type that isn’t registered with Qt’s type system.

(As an aside: If you have existing code that compares a type id to QMetaType::Void (or to the integer 0), I recommend double-checking your logic when switching to Qt 5 (“should this be checking for void, unknown types, or both?”).)

For consistency with QMetaType, QMetaMethod::typeName() in Qt 5 returns the string “void” if the return type is void. Existing code that assumes that an empty typeName() string means void will have to be adapted accordingly (compare the returnType() to QMetaType::Void instead).

Method parameters

Similar to QMetaMethod::returnType(), the new function QMetaMethod::parameterType() returns the meta-type id of a parameter. QMetaMethod::parameterCount() returns the number of parameters. Consider using those two functions instead of the old QMetaMethod::parameterTypes() function, which returns the types (names) as a list of strings.

If the type is known at meta-object definition time (a built-in type, in the moc case), the type id will be embedded directly in the meta-object data, resulting in very fast lookup. For other types, the id resolution will fall back to string-based lookup, which is no slower than before. (It could be improved by caching the resolution somehow.)


For Qt 5, the meta-object system (and the meta-type system, too, but let’s save the details for another post) has gone through a small metamorphosis. Methods are now represented and manipulated with proper semantics, not as plain (C) strings. Source compatibility with Qt 4 was largely kept (if it ain’t broke, don’t fix it — but a few things were broke in Qt 4, and we were compelled to fix them). We cleaned out some legacy stuff in the implementation. Several Qt modules already use the new features, resulting in cleaner, faster code. Surely even the most staunch meta-critic will be appeased.

Author: "Kent Hansen" Tags: "C++, Qt"
Comments Send by mail Print  Save  Delicious 
Date: Monday, 18 Jun 2012 15:35

Qt 5 is a very gradual and smooth update from Qt 4. There are generally no breaks in source compatibility, except where we felt that it’s absolutely necessary.
One area where we actually decided to do major changes that will affect people porting to Qt 5 is accessibility.
The reason is that we were really hindered in improving and modernizing Qt’s accessibility implementations on all platforms by the old state of the API.

For the moment we marked all accessibility APIs as internal. That means they are “hidden” and won’t show up in the documentation. This is because of the big changes where we are not quite sure that the new APIs have been tested enough. We feel that the Qt 5.1 release is the right time. But we have all enablers in place so that anyone willing to test should be good to go without any special setup. This means that while for the time being it’s undocumented you can expect it to work much better than in Qt 4 already.

The work on the new linux accessibility bridge with the help of users giving feedback showed us the limitations that we now tried to address as much as possible. The orginal API was inspired by MSAA which is the accessibility API that Windows 95 supported.
As you may guess, since then the world moved on and much happened in order to enable developers to support users better and of course enable users to make the best out of their computers. While we did not do any revolutionary changes, many details have been polished, the API is much cleaner and less error-prone. One huge improvement is how notifications are sent to the platform, finally providing enough details to the tools.

In Qt 5 after taking a step back we have improved platform integration on Mac, Windows and Linux. This will be the first Qt release which offers a good accessibility support on all desktops. We also extended our effort towards QML next to the traditional QWidget world. There are still some open questions, but the current system has actually already been tested extensively, for example in Unity-2d which is well liked by users of screen readers using Ubuntu, showing that QML and accessibility can go hand in hand.

For Mac we finally have a Cocoa backend instead of the dated Carbon one. This bridge (bridging the Qt accessibility APIs to the Mac API) is still young and fresh and thus needs your help in testing and polishing it.

The Windows accessibility bridge now supports IAccessible 2 next to MSAA which should give much better support for many elements such as tables and lists to the screen readers.

For Linux the new qt-at-spi bridge has been tested with Qt 4 and works with Gnome and KDE. For Qt 5 it has seen major improvements and will be merged to be shipped with Qt itself (as plugin), either for Qt 5.0 or 5.1.

Application developers should expect more accessibility features and better screen reader support out of the box on all platforms. It is to be expected that it’s not yet perfect, thus give us feedback. If you did support more extensive accessibility features and your own widget implementations subclassing QAccessibleInterface we’re especially keen on hearing from you. The documentation is all there, so feel free to read the comments in the .cpp files explaining the improved classes.

Author: "Frederik Gladhorn" Tags: "Accessibility, Qt, Desktop, Linux, Mac, ..."
Comments Send by mail Print  Save  Delicious 
Date: Wednesday, 06 Jun 2012 10:59

According to this recent poll, Desktop Components is one of the most desired add-ons for Qt Quick 2. To help make this a reality we have moved the Desktop Components project over to codereview.qt-project.org and are now accepting contributions, for both the Qt Quick 1 & 2 versions. Several good contributions have been made already, and at the same time a few of us here at Nokia have been working on bringing the components up to speed on Qt 5.

The components are hosted as a Qt Playground project and won’t be a part of the 5.0 release. They will instead have separate releases, most likely in sync with the Qt 5 releases. At some point we will look at making them a proper part of Qt 5.

Project details are available at the wiki. Here’s a quick getting started script:

git clone https://git.gitorious.org/qtplayground/qtdesktopcomponents.git qtdesktopcomponents
git checkout qt5
make install
cd qmldesktopviewer; qmake; make; cd..
qmldesktopviewer/qmldesktopviewer examples/TopLevel.qml

Do you want to contribute? There are several open tasks, including:

  • Add a menu bar component
  • Add support for mouse wheel events
  • Style polishing on your favorite platform
  • Update: Tree View!

Finally, screenshot time (all on Qt 5):


Mac OS X



Author: "Morten Johan Sørvig" Tags: "KDE, Mac OS X, Qt, Windows"
Comments Send by mail Print  Save  Delicious 
Date: Wednesday, 09 May 2012 14:02

The Qt Creator 2.5.0 final has been released! There are lots of new features and improvements in this release, I’ll highlight a few here, some others are probably already mentioned in our beta blog post, and you’ll find a more complete list in our changes file.

So, new features and improvements include but are not limited to:

  • You can repeat a recent search with the same parameters with a simple click on “Search Again”
  • “Execute” Locator filter lets you run arbitrary commands in a shell from Qt Creator (“! <some command>”) (thanks to Yuchen Deng!)
  • Experimental plugin that shows “TODO” items from your sources (thanks to Dmitry Savchenko and Vasiliy Sorokin!)
  • Experimental plugin for autotools based projects (thanks to Patricia Santana Cruz and Openismus GmbH!)
  • Mac OS X Lion users will we happy to know that QTCREATORBUG-6222 which prevented adding some Qt Versions has finally been fixed
  • A very basic version of a C++ refactoring action that adds an #include for an unknown identifier has been added (move cursor on identifier, press Alt+Return (Option+Return on Mac OS X))
  • A very basic version of a C++ “extract method” refactoring action
  • Improved support of C++11 (nullptr, constexpr, static_assert, noexcept, inline namespaces, auto, lambdas)
  • Rearrange C++ method arguments (thanks to Bojan Petrovic!)
  • New hints and warnings for QML code, including an option to prevent them for specific lines (with a special comment)

Note for Windows MinGW Users

We decided to remove the custom MinGW distribution and MinGW gdb from our Qt Creator-only Windows binary distribution package. The original reasons to include it there (it was the predecessor of the Qt SDK) are since a while now filled by the Qt SDK. Also, updating the shipped version is a legal hassle as long as the binaries are provided through Nokia, but we also don’t want to ship stone age versions. We are working on build infrastructure for the Qt Project itself though, that we ultimately want to use to build Qt Creator packages, snapshots, and more. Currently, on http://builds.qt-project.org, you find Qt Creator snapshots for Linux and Windows, and also a Python enabled MinGW gdb (that reportedly doesn’t work on Windows XP). It’s still possible to install MinGW and gdb separately and register them in Qt Creator. We are not removing the support for it from Qt Creator.

Previously shipped MinGW: ftp://ftp.qt.nokia.com/misc/MinGW-gcc440_1.zip
Previously shipped MinGW gdb: ftp://ftp.qt.nokia.com/misc/gdb/7.2/qtcreator-gdb-7.2-mingw-x86.zip

Up to date MinGW: http://www.mingw.org (we might provide a compact version like the one in the old installer later)
Python enabled MinGW gdb 7.4: http://builds.qt-project.org/job/gdb-windows/ (compiled on Windows 7, doesn’t work on Windows XP)

Thanks to All Contributors

Too many to include them all here, please scroll to the end of our changes file!


See our Release Page

Author: "Eike Ziller" Tags: "Qt, QtCreator"
Comments Send by mail Print  Save  Delicious 
Date: Monday, 23 Apr 2012 13:00

We are happy to announce the Qt Creator 2.5 release candidate today. Since the beta release we did a lot of bug fixing, including some crashes and some regressions in the C++ code model handling. Thanks to all who contributed to these 180+ fixes. And special thanks this time go to Leena, for all the effort she put into updating our documentation and screenshots again!

Featurewise I refer you to the beta release blog post. One thing we didn’t mention there though is another new (experimental) plugin for direct support of autotools projects. If you work with autotools based projects, you might want to check this out instead of using the generic “Import existing project”. Just enable Help > About Plugins > Build Systems > AutotoolsProjectManager, restart Qt Creator, and open a Makefile.am. Many thanks to Patricia Santana Cruz and Openismus GmbH for contributing this plugin.

Download page

Changes file

Author: "Eike Ziller" Tags: "Qt, QtCreator"
Comments Send by mail Print  Save  Delicious 
Date: Wednesday, 18 Apr 2012 09:52

We have seen the many questions and the concerns raised about our commitment to C++ and QWidget in Qt 5. I thought now would be a good time to address some of these concerns in this post.

The post on the Qt 5 alpha was focused on the new things we enable and add with Qt 5.

Let me just state it very clearly here:

QWidget and all derived classes are a core part of Qt 5 on the Desktop.

You can continue writing your application in exactly the same way as you have been doing with Qt 4.x.

We have promised to try to keep as much source compatibility with Qt 4.x as we can. And of course this includes QWidget and your application written in C++. This is not going away. Yes, the Qt Widgets module we have in Qt 5 is right now marked as ‘done’, which means we don’t have anybody actively working on new features for the module at this point in time. But this can change any day if someone has some interest or need to do more active development in this area.

What we did with Qt 5 is to add a new way to do applications with QML. I personally believe that over time we will see more and more apps being written that way, as I believe it is the better solution in the long term.

New user interfaces such as the Windows 8 Metro UI are not things we could simply add to our existing QWidget infrastructure. Adding support for the kind of animations used in these user interfaces is extremely difficult using QWidgets, as they were designed for the mostly static user interfaces that predominated until a couple of years ago.

The fluid animated user interfaces that are already there on Devices such as smartphones and tablets are now also starting to appear also on desktops. And they are simply not implementable using the QWidget infrastructure.

This implies that we needed to do something new here. And QML/Qt Quick was the answer we came up with to solve this problem. That’s why we’re investing in that area.

Our experience with QML over the last years has shown us that it is the superior technology for building UIs in the long term. If you want, you can simply use it as a more powerful replacement to .ui files. But you can also write some application logic in there using Javascript if you want.

It really is up to everybody what they make out of the options being given by Qt 5, and how they best like to use them.

C++ is and will stay our main programming language.

We have done significant work for Qt 5 adding many new C++ APIs. We have added support for C++11 in many places. And we’ll continue to do so, because larger scale applications written with Qt will be mostly written in C++ for a long time to come. And there’s nothing bad about this.

What we did with Qt 5 is to add another option into the mix. We want to make the usage of Javascript supported as well as C++ is supported. We are not making it the superior way or even the only way. That is a good thing, as it opens up new options for how you write your application.

If you want, you can do smaller pieces of application logic inside QML. It allows to do some rapid prototyping that can then be replaced by C++ in the final implementation. It gives you abilities to do application scripting. And for many apps it also gives you the option to write a big part of it in QML and Javascript.


With Qt 5, if you want to use Qt as you have always used it, please go ahead. It’s a fully supported way of doing things.

But I do believe that we will need more then what we have in Qt 4 for the longer term future. The expectations towards application UIs are changing drastically, especially when creating consumer-facing apps.

We need to have solutions available if we want Qt to stay relevant. That’s what Qt 5 is all about.


Author: "Lars Knoll" Tags: "C++, Contributors, Qt"
Comments Send by mail Print  Save  Delicious 
Date: Friday, 13 Apr 2012 01:57

Cross compiling Qt for particular devices/BSPs can be frustrating when operating from first principles and we are trying to improve the existing configure/qmake build infrastructure in Qt 5, as well as the associated documentation, in order to ease this burden. We are approaching the problem from 2 angles:

  • General cross compilation support
  • Direct target support

The general cross compilation support is being improved by:

  • Reworking the pkg-config logic
  • Introducing the -device flag to configure
  • Introducing the -sysroot flag to configure

The supported targets are documented here:


and as you can see in the Raspberry Pi documentation, we have reduced compilation for this target down to:

./configure -prefix <your prefix> -release \
  -device linux-rasp-pi-g++ -make libs \
  -device-option CROSS_COMPILE=<your toolchain path>/bin/arm-none-linux-gnueabi-
  -sysroot <your sysroot path>

The resulting build has full (single process) OpenGL ES 2 support and keyboard support for the Raspberry Pi.

There is no need to patch any files as all the relevant changes have been upstreamed into Qt 5 where they can be adequately reviewed and QAed like any other Qt contribution. Needless to say this drastically increases the quality of the code finding its way on to these devices and should drastically improve the user experience when dealing with this kind of hardware for prototyping/productization/recreation. Sunlight is the best disinfectant, and we delight in consuming this dog food.

We heartily invite any (all!) chipset vendors/chipset customers/BSP vendors or interested parties to upstream relevant mkspecs and the associated code changes to Qt, in order to extend the breadth of Qt 5′s out-of-the-box device support. The move to Open Governance has made extending this support increasingly achievable, feasible and convenient and we are very excited about both Qt 5 as a whole and the current rate of development towards embedded (read constrained) Linux platforms.

Author: "dcarr" Tags: "Contributors, Embedded, Open Governance,..."
Comments Send by mail Print  Save  Delicious 
Next page
» You can also retrieve older items : Read
» © All content and copyrights belong to their respective authors.«
» © FeedShow - Online RSS Feeds Reader