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!

Download

See our Release Page

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

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.

Summary

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.

Cheers,
Lars

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:

http://wiki.qt-project.org/Devices

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.

Well its taken 3+ years for Qt 3D to be an overnight success, but here it is: we are now part of Qt5 and we’ll be front and centre in the exciting picture that will be powering a new generation of QML enhanced apps on a whole range of platforms. As a Qt5 Essential Qt 3D will be running on all those supported Qt5 platforms providing OpenGL accelerated 3D content defined in QML. Its great news for us in the team, and good news for those of you using Qt 3D or planning on using it for your projects.

If you’re a Qt 3D fan and have been following the project for a while you’ll know that as a labs project we had to do our own releases, carefully making sure that packages we created matched the current supported versions of Qt 4. We have in the past released easy-to-use packages for Symbian^3, N900 and the N9 platforms, as well as for Windows desktop; and supported Linux and Mac with source packages. We got great feedback from those package releases, and saw some interesting projects built on Qt 3D.

As part of Qt5 the SDK team and release program will make Qt 3D available through official Qt5 release activities. This will free us up to spend more time on performance, bug-fixing and best of all the features that we’ve been asked for. This is fantastic news for us since packaging consumed quite a bit of our resources, and now we can focus that on improving Qt 3D.

Before we move away from Labs status we are making one more Qt 3D labs release: and this is it. This follows our Qt 3D TP1 and TP2 releases with a 1.0 release as part of our Qt 4.x programme. In this release are a number of important bug fixes, some new stuff like threaded texture and model loading, and the new Qt 3D Asset Viewer, which allows you to visually configure the models you load into your Qt 3D applications.

Today we announce our Qt 3D 1.0 for Qt 4.8.1 with only a small amount of fanfare: this will be our last 4.x major version release.

• Windows binary package
• Source package for Mac/Linux/N9
• Documentation package.

For Windows folks, you’ll need the Qt 4.8.1 Windows MSVC release which is available from the Qt downloads page.

The documentation is also available on-line on the Qt project site.

For N9 developers we no longer create a package. The publicly available Qt SDK can build these packages for you from our source download using the Qt 4.7.x Harmattan support, that is built right in to your SDK. Just follow the special N9 instructions in our build documentation. For Symbian likewise you will need to create your own packages. For folks using a MinGW based Qt on Windows, you will need to use the source package also.

Why are we not supplying N9 or Symbian packages for Qt 3D 1.0 against Qt 4.x? Since Qt 3D 1.0 for 4.x is a labs project, our previous device packages were not official Nokia system packages, and just functioned as a convenience to the developer. This is why we’re asking that you create your own packages to underscore the fact that Nokia does not supply Qt 3D system packages as part of Qt 4.x, and you’ll need to do your own work to include any Qt 3D functionality in your device apps. Apologies for this, but its the way it is for our 4.x labs status programme. Qt 3D team remains available on IRC and via our email lists (see below) to support you as far as possible when including Qt 3D in your apps, but unfortunately for Qt 4.x we cannot supply Nokia system packages for these platforms.

What about Qt5? That is where the excitement lies, with a vastly improved QML rendering engine, which has the benefit for Qt 3D of guaranteed OpenGL support. If you have QML2 then you have OpenGL and that means Qt 3D is ready to go on any Qt5 platform. We’d love you to try out Qt 3D on Qt5 – go and check out the Qt5 Alpha release which has just been announced, and tell us what you think. If you want to try out the bleeding edge, you can also get Qt 3D in Qt5 by building from Git.

Today we released the Alpha of Qt 5, the first major release since the Qt Project went live. A lot of people have worked hard to make this release happen. A large amount of work and features that went into this alpha have been coming from people not working for Nokia. It’s great to see that the project has become a place where many people meet and together push Qt forward.

The main purpose of the Qt 5 Alpha release is to get feedback that helps us make the coming releases better. For the Alpha we focus on the delivering the Qt Essential modules, which forms the foundation of the functionality Qt 5 will offer.

The alpha can be downloaded from http://qt-project.org/wiki/Qt-5-Alpha. Note that the alpha release is a source-only release without binaries to download, so you need to build the binaries yourselves. Build instructions can be found at http://qt-project.org/wiki/Qt-5-Alpha-building-instructions

We have now been working for around 9 months on Qt 5, following the ideas I outlined in a blog in May last year. The blog talked about a couple of objectives we had for Qt 5, and I’d like to reflect a bit on what we achieved.

The Vision

There was one basic vision driving a lot of the Qt 5 work:

“Qt 5 should be the foundation for a new way of developing applications. While offering all of the power of native Qt using C++, the focus should shift to a model, where C++ is mainly used to implement modular backend functionality for Qt Quick.”

I can say that we came a good way closer to this vision with Qt 5.0. The model is working nicely on the embedded side of Qt where UIs are full screen. On the desktop, we have laid most of the foundations required for this model, but it’ll take us until 5.1 or 5.2 to really take this into use.

Developing in the open

We wanted to develop Qt 5 in the open, with a strong community around it. Since the launch of qt-project.org, we have seen a vibrant community forming there, and many of the patches and new features we will have in Qt 5 are coming from the community.

Four big architectural changes

Then we had set out to do four major changes to Qt’s internal architecture:

1. Base all Qt ports on Qt Platform Abstraction layer (QPA) – Make it easier to port Qt to other windowing systems and devices
   With QPA we have fundamentally changed how Qt integrates with the windowing system of the underlying OS. QPA was introduced in Qt 4.8 as a replacement for QWS/Qt Embedded, but is now used exclusively for all platforms. This move created a lot of work and forced us to rewrite a very large part of pour platform dependent code. But it also helped us create a much cleaner architecture where the platform dependent code is nicely abstracted. We can see that the new abstraction makes it significantly easier to write integration with new windowing systems, and the backends that are being written for QNX, Android and iOS prove this.
2. Re-architect our graphics stack – Increase performance versus Qt 4, using Qt Quick and OpenGL (ES) 2.0
   Qt 5 introduces a new graphics architecture for Qt Quick, using a Scenegraph on top of OpenGL. This requires OpenGL (ES) 2.0 at the minimum to work. QtGui now contains a set of QOpenGL* classes, that replace the old QGL* classes (they are still available for compatibility). We also introduced a new QGuiApplication class that is more lightweight than QApplication and a QWindow class for handling top level windows on the screen.The QWidget based stack continues to work as in Qt 4.x, based on QPainter. QPainter does however support less backends than it used to. It is now limited to SW rasterization (Raster backend) for drawing to the screen, pixmaps and images, an OpenGL backend for GL surfaces and a backend for PDF generation and printing. The platform dependent backends using X11 or CoreGraphics are gone.This allows us to introduce the new graphics architecture for the long term while keeping full compatibility with Qt 4.x on the QWidget side.
3. Modular repository structure for increased flexibility and to meet the merge of desktop and mobile – add /remove user specific modules as needed and a full integration of the Qt mobility APIs
   This is mainly an internal housekeeping item, that won’t be directly visible to developers using Qt. But the modularization of the Qt repositories makes it easier for us to move the different parts of Qt forward in a more independent way. This will become increasingly important now that Qt 5 is stabilizing and once we release 5.0 and start keeping binary compatibility.The modularization is not yet fully done, esp. the qtbase repository still contains many modules that should be separated. So this work will most likely continue after 5.0 is out.The modularization of Qt also makes it a lot easier to integrate contributions in form of 3rd party modules to Qt. It also responds to the trend of having different requirements on laptops and tablets/mobiles with regard to especially mobile features such as locations, sensors etc.In Qt 5 we will see the Qt mobility APIs as an integrated part of Qt – some of them as part of the group of modules that are seen to be essential for Qt = “Qt Essentials”. By offering the modular approach, other modules can be added in a simple way, and we are already today sure that Qt5 will offer a richer feature list than any earlier Qt version. Please notice that this alpha release is focused on Qt Essentials.
4. Separate all QWidget related functionality into its own library
   By separating QWidgets into a separate repository, we secure a continued use of QWidgets for those that desire, but also a path to a model where all UIs are being done in QML and Qt Quick. Separating the QWidget based functionality into its own library is therefore a good measure to achieve a clean architecture in Qt 5 in the long term.

The announcement of these changes created a lot of response, and we have already addressed a lot of the common questions about Qt 5 and these architectural changes earlier.

New functionality

In addition to the architectural changes, Qt 5 also offers a lot of new functionality. I’d just like to highlight a couple of them here, you can find a detailed list with descriptions on our wiki.

• Qt Core
  Many new features have been added to QtCore. We now have a QStandardPaths class giving you the standard locations for things such as media and documents on your platform. A JSON parser and speed optimized binary format for JSON are included. We have added support for Mimetype recognition, both on extension and file content. A new compile time checked signal/slot connection syntax has been added and we have a completely new Perl compatible regular expression engine included.Many of our data structures have been rewritten and optimized for better performance. We also added C++11 support where it makes sense. But Qt continues to compile and work with a C++98 compliant compiler.
• Qt Gui
  All QWidget based classes have been separated out into the QtWidgets library. QtGui has gained support for top level surfaces through the QWindow class, and now has builtin OpenGL support.
• Qt Network
  We added support for DNS lookups and removed the QHttp and QFtp classes (they are available standalone for those that need them). Lots of smaller improvements.
• Qt Widgets
  Got ported over to the new QPA architecture and should work as you are used to from Qt 4.x.
• Qt Quick
  The Qt Quick from Qt 4.x times is now available in a Qt Quick 1 module and fully compatible. That module is done and won’t be developed any further.Focus here is now on the new Qt Quick and Qt Qml modules. In Qt 5 we have separated the graphical parts of Qt Quick from the QML and JS language into separate modules. The new JS classes (QJSEngine and QJSValue) are now using Google’s V8 engine behind the scenes giving us much better performance for JavaScript. The QML engine has also undergone lots of performance improvements and some enhancements to the language.The Qt Quick module contains the OpenGL based Scenegraph and all the basic items that are known from Qt Quick in Qt 4.x. We added support for GL based shader effects, particles and many other things. On the QML side things are mostly source compatible, but when writing QML items in C++ some changes are needed to adjust to the new scene graph.
• Qt 3D and Qt Location
  Some additional modules have been added to the set of Qt Essentials, most notably Qt 3D to integrate 3d content with Qt and Qt Location giving access to GPS, Maps and other location based services.
• Qt WebKit
  The WebKit C++ APIs have not changed since Qt 4.x, but Qt Webkit got updated to a newer version from webkit.org giving us many improvements and better HTML 5 compliance. Compilation is currently disabled on Windows for this alpha, as building it right now is rather complex. We’re working on having this re-enabled and fully working for the beta.

Porting from Qt 4.x to Qt 5

There is a binary and to a smaller extent source compatibility break between Qt 4.x and Qt 5. We have however worked hard to make an easy and smooth transition of existing code to Qt 5 possible. As an example we currently have Qt Creator compiling and running against Qt 4.x and Qt 5 using the same code base.

If you want to try out your own project against Qt 5, you can find detailed porting instructions here.

Please also note that there is no immediate need to port your app to Qt 5, as Qt 4.8 is still there and supported by the community and companies such as Digia for some time to come. But we firmly believe that Qt 5 will offer enough benefits to consider moving.

Next steps

As you can see a lot of things have happened since the work on Qt 5.0 started. I am very happy with what we have achieved so far. You can now all help us finalizing Qt 5 by downloading the alpha, trying it out and giving us feedback.

All feedback should go to the qt development list (development@qt-project.org, see also lists.qt-project.org), or simply reported as bug reports in our bug tracking system. Any patches and bug fixes are of course also highly welcome, please submit these to codereview.qt-project.org.

The Alpha is the first step towards a final release of Qt 5, and focus from now on will be fully on ironing out the remaining issues so that we can deliver a final Qt 5.0 to you as soon as possible.

There have been too many people involved in getting to this point to mention them all, but I’d like to say thanks to every one who has contributed in some form to this release.

Enjoy!

Lars

We just published the Qt Creator 2.5 beta. This release is full of goodies, and as usual we’d like to give you a small tour through the new features, though we can’t possible cover all of them in one blog post.

The C++11 standard was published last September. We are happy that Qt Creator 2.5 understands more of C++11 e.g. nullptr, constexpr, static_assert, noexcept, inline namespaces, auto, and partially lambda. And as usual we implemented some new refactoring operations, such as:

• A basic refactoring action to insert an #include for an undefined identifier
• A “extract function” refactoring action
• A “rearrange parameter list” refactoring action
• Signature synchronization: changing parameter names in the declaration automatically changes them in the function body

The debuggers used on Linux and MinGW also pretty print some of the new C++11 types, such as std::shared_ptr, std::unique_ptr, std::array. In addition pretty printers for std::complex, boost::posix_time::{ptime,time_duration}, boost::gregorian::date are new in Qt Creator 2.5. Also more often than before, Qt Creator figures out the correct dynamic type of your pointers and thus pretty prints using the dynamic type.

One day before the 2.4 beta was released Open Governance launched. Since then, 78 people used Codereview to submit patches to Qt Creator. That’s great and shows the power and ease of use of gerrit. If you haven’t used gerrit yet, it’s a tremendous improvement to gitorious. It takes a few commands to set up gerrit but afterwards publishing a patch for review is just one git push away, but don’t forget to add reviewers to your change.

One of the big contributions to 2.5 is a TODO plugin. It is still lacking some polish so it is disabled by default, though it is already quite useable. Please give it a try by enabling it in Help/About Plugins. Many thanks to Dmitry and Vasiliy. We would like to thank everyone that contributed to Qt Creator and like especially highlight the good work that Orgad does, not only did he contribute over 30 commits to this release but he’s also the most active bug reporter apart from our QA team. In fact, he found a crash just hours before the beta release.

Apart from those big features, 2.5 also includes lots of small features, to mention just two:

• A clipboard history, use Ctrl+Shift+V to cycle
• Showing small icons for build errors in the editor margin and updating the line numbers of build errors while editing. See the screenshot above.

And then, before I forget, check out the previous blogs on Debugging Qt Quick 2 – Console API and QML Profiler update .

For even more information on the changes in 2.5, see the changelog.

You can download Qt Creator from http://qt-project.org/wiki/Qt_Creator_Releases

We appreciate any bug reports, feedback, patches via the mailing list, the bug tracker, gerrit and the #qt-creator IRC channel on freenode.

Qt Quick brings a lot of flexibility and speed to development. Traditionally one had to do the “compile, package, deploy, run” cycle over and over again, whereas with Qt Quick you can now do incremental changes to your source even at runtime! In Qt Creator, we are trying to leverage the power of Qt Quick, version by version. However, as with any programming language there is a downside. Script compilation errors are runtime errors in QML, sometimes you’re trying to wrap your mind around QtDeclarative binding loops, JavaScript has many dark corners that you don’t want to be caught in and so on… All these potential pitfalls mean that a good debugger, profiler and inspector are weapons you really want to have

The focus in this blog post is on debugging and the most straightforward debugging technique: The console API. Chances are high that you’ve already used it in your first helloworld.qml file, since console.log() is a part of it. We recently updated Qt 5 with some of the most useful methods from the FireBug console API (a defacto standard in web browsers).

Logging

We’ve been supporting console.log and console.debug since Qt Quick 1.0. The print() from QtScript days still works but as it has a slightly different meaning, when you execute it in JavaScript code in a web browser, it should be left alone. In Qt 5 we added a few more logging functions. All the calls are directly forwarded to its Qt counterparts:

Yes, at the moment, console.log(), console.debug(), and console.info() have the same functionality! Since they are some of the most often used methods and can be found in countless JavaScript code snippets on the net, we’re supporting them. Maybe it’s also food for thought that we should add an additional log level to qlogging.h

Profiling

Ever wondered about how long a particular code path takes? Take for example the logic in your onCompleted method.

Component.onCompleted() {
  console.time("onCompleted");
  // ...
  console.timeEnd("onCompleted");
}

will print the time in milliseconds. The string argument is both an identifier for the particular measurement (you can also make interleaved measurements) and the prefix for the output:

onCompleted: 401ms

For a more in-depth analysis there’s console.profile(), console.profileEnd().

Component.onCompleted() {
  console.profile();
}

Component.onDestruction() {
  console.profileEnd();
}

The API pair profiles both the state of the QDeclarativeEngine as well as V8 method calls. However, to retrieve the data you have to attach the QML Profiler tool to your application before calling console.profileEnd() else the profiling data is lost. Christiaan Janssen has already described the QML Profiler tool that ships with Qt Creator in a previous post here. A standalone profiler tool is available in Qt 5 that saves the profiling data in a file. This file can then be read using Qt Creator.

Still More…

We have also introduced the following APIs:

console.assert() : To test an expression and print an optional message and the stack trace of JavaScript execution if the expression evaluates to false.

console.exception(): Prints an error message and the stack trace of JavaScript execution.

console.trace(): Prints a stack trace of JavaScript execution at the point where it is called.

console.count(): Prints the number of times this function is called along with a user provided message.

Script Console – New Avatar

The QML console was first introduced in Qt Creator 2.1. However, it was a simplified console limited to evaluating simple expressions. We felt that Qt Quick2 developers need a more advanced console to unleash the power of QML.

We introduce to you the new avatar of the QML Console a.k.a. Script Console.

Script Console in Qt Creator

Apart from evaluating expressions, the Script Console shows the debug output, both Qt debug messages and JavaScript console messages, in a pretty way You can use the filter buttons located in the top right corner to view logs that appeal to you. For example, if you want to see only the errors, then de-select the info and warning buttons and Voilà! The debug output also shows the file and line info and clicking on it opens the relevant file in the editor with the cursor on the particular line. No more do you need to add context info in your output messages to locate them in your source code. Also you can always rely on the Find toolbar to search for text in the console.

JavaScript objects and arrays are shown in an expandable tree in the console. The current context, which is used to evaluate the expressions,  is displayed in the status bar. The Script Console can be used even when not on a debug break to inspect and evaluate QML elements and expressions. The Script Console also supports multi-line input. It also remembers your previous inputs so that you don’t need to type that really long expression again.

The best thing is that you do not have to wait for too long as the Script Console will be a part of Qt Creator 2.5.

What’s missing?

We haven’t implemented the methods dealing with the console so far, just because they don’t make too much sense when your console is just the command line. For example, it would be hard to implement console.clear() in a portable way We left out console.group(), console.groupCollapsed(), console.groupEnd(), console.table(), console.dir(), console.dirXml() for similar reasons.

The Script Console in Qt Creator is WIP.  Currently, QML objects and arrays are not shown in a tree. The console still needs polishing and do expect more features in later versions.

We are eager to hear your wish list and your experiences with the console. You can contact us via the qtcreator mailing list or on IRC at the freenode server, channel #qt-creator.

Introduction

A topic which has been receiving quite a bit of attention recently is the use of shader programs to apply effects within Qt Quick applications. Once you have grasped the basics of the shader programming language, embedding the shaders in your application is made really easy by Qt Quick, with the result that stunning visual effects can be achieved from a surprisingly small amount of code.

What hasn’t been mentioned previously in this blog is that applying shader effects to multimedia content (video playback, or a camera viewfinder) is just as easy as transforming any other QML element. This post shows some of the results you can achieve by combining shader programming with QtMultimedia.

The best way to demonstrate some of the effects you can achieve is … with a demo, so that’s where we’ll start.

The videos above show a Qt Quick 2 demo app, running on a desktop Linux machine. Aside from some ancillary C++ code (listening to scene graph signals in order to calculate the frame rate, and reading shader programs from the file system), the app is entirely written in QML.

Implementation details

As previously described, Qt Quick 2 comes with built-in support for shader effects via the ShaderEffect QML element. Using this to apply an effect to video or viewfinder content really isn’t any more difficult than applying the same effect to any other QML element. To illustrate this, the code snippet below shows a time-varying wobble effect being applied to a video clip which is played from a file.

import QtQuick 2.0
import QtMultimedia 5.0

Rectangle {
    width: 600
    height: 400

    MediaPlayer {
        id: mediaPlayer
        autoplay: true
        source: "test.ogg"
    }

    VideoOutput {
        id: videoOutput
        anchors.fill: parent
        source: mediaPlayer
    }

    ShaderEffect {
        anchors.fill: parent

        // Properties which will be passed into the shader as uniforms
        property real amplitude: 0.02
        property real frequency: 20
        property real time: 0

        NumberAnimation on time {
            loops: Animation.Infinite
            from: 0
            to: Math.PI * 2
            duration: 600
        }

        property variant source: ShaderEffectSource {
            sourceItem: videoOutput
            hideSource: true
        }

        fragmentShader: "
            uniform highp float amplitude;
            uniform highp float frequency;
            uniform highp float time;
            uniform sampler2D source;
            uniform lowp float qt_Opacity;
            varying highp vec2 qt_TexCoord0;
            void main() {
                highp vec2 p = sin(time + frequency * qt_TexCoord0);
                highp vec2 tc = qt_TexCoord0 + amplitude * vec2(p.y, -p.x);
                gl_FragColor = qt_Opacity * texture2D(source, tc);
            }
        "
    }
}

Applying the effect to a viewfinder stream rather than to video playback is simply a matter of replacing the Video element with a Camera element.

In the qmlvideofx demo, each effect is implemented as a QML element which inherits from ShaderEffect; these elements are dynamically loaded and applied to the video content when the user selects the corresponding effect from the menu. Similarly, the different inputs (image, video and camera) are represented by QML elements which are dynamically loaded when required.

The set of parameters supported by each effect (e.g. ‘granularity’ for Pixelate; ‘radius and diffraction’ for Magnify) is exposed as a ListModel which is used to construct sliders via which the parameter values can be adjusted.

The code (Qt 5.x)

The source for the qmlvideofx demo can be found in the qtmultimedia repository here:

https://qt.gitorious.org/qt/qtmultimedia/trees/master/examples/video/qmlvideofx

Until Qt 5.0 is released, you’ll have to build it from source in order to build and run the demo. Instructions for how to do that can be found on the wiki here. The required subset of Qt modules can be cloned as follows:

$QTDIR/init-repository --module-subset=qtbase,qtdeclarative,qtjsbackend,qtmultimedia,qtxmlpatterns

The code (Qt 4.x)

While Qt Quick 1 does not have built-in support for shader effects, it is provided by the Qt.labs.shaders plugin, which is shipped with Qt from version 4.7.4 onwards. A Qt 4 version of the demo is available here:

https://qt.gitorious.org/qt-mobility/qt-mobility/trees/master/demos/video/qmlvideofx

In addition to running on desktop platforms (tested on Linux and Windows), the Qt 4 version of the demo will also run on mobile devices – the video below shows it running on a Symbian device (Nokia C-701).

Keen-eyed viewers will notice that the app has a slightly different UI to the desktop version – thanks to the flexibility of Qt Quick, that is achieved by substituting a single QML file which describes the layout.

It should be noted that the app will not run on currently available versions of the Symbian platform. The reason is that it requires the output of the video decoder to be available to the OpenGLES engine as a texture. An EGL extension which allows the video and graphics stacks to cooperate in this way (EGL_NOK_image_endpoint2) will be added in a future Symbian release. Once this is available, QtMultimediaKit will automatically make use of it (see QTMOBILITY-1818), and the demo will start working.

You can, however, run the app today on the Nokia N9 – as shown by the video below.

Further information

If you weren’t already excited about the potential of shader effects, hopefully you are now. Below are some links to other examples of their use in conjunction with Qt/QML.

• Qt Labs Blog: Qt Graphical Effects in Qt Labs
• Qt Labs Blog: The convenient power of QML Scene Graph
• Qt Labs Blog: QML Scene Graph in Master
• YouTube: Raspberry Pi, Qt 5, QML, Shaders
• YouTube: Livecoding video effects with Qt5

Over the years we have developed a kind of a love-hate relationship towards qmake. It does its job but also has its quirks and is widely considered unmaintainable. The blog post [TMQB] contains a wish list for a qmake replacement. We have considered the various tools on the market, but none satisfied us – see for example [WNCM]. So some time ago we have initiated an internal project to try some of the ideas. This is the outcome of it: the Qt Build Suite, aka qbs (pronounced as “Cubes”).

It is not qmake

Unlike qmake, qbs is not tied to the Qt version, and it generates a proper build graph (dependency graph) from the high-level project description in the project file. Also, classical makefile generators like qmake and CMake create makefiles and leave the execution of the actual build commands to tools like make or ninja. Qbs on the other hand fills the role of a parallel make and directly calls the compiler, linker and other tools, pretty much like SCons and Ant do.

Declarative Language

The language of qbs is a simplified version of QML, providing an IDE-friendly representation of software projects. Still it provides the freedom of writing all kinds of JavaScript expressions on the right-hand-side of property bindings. A project file editor could know how to edit file lists that are pure string array literals. For more complicated constructs it would fall back to opening the project file in a text editor.

files: ["foo.h", "foo.cpp", "main.cpp"]              // editable from IDE
files: generateFileList().concat(['extra.cpp'])      // only editable in your text editor

For most use cases it should be possible to write IDE-friendly project files. But if you need more power, you are free to unleash all your l33t JavaScript skillz.

Now let’s have a look at the obligatory “Hello World” example:

// helloworld.qbp
import qbs.base 1.0

CppApplication {
     name: "HelloWorld"
     files: "main.cpp"
}

The import statement enables us to use items like “Application”. We are giving our application the name “HelloWorld” and adding a C++ source file to it.

A thorough walk-through of the language can be found in the documentation under “language introduction”.

Extensible

Dealing with code generators or resource compilers is something you really want to avoid in qmake. In qbs you can easily write rules to transform files of a certain type to files of another type. One can either call processes that do the transformation externally (e.g., rcc) or directly execute the transformation in JavaScript. This simplified example demonstrates how to turn the .pluginspec.in files of the Qt Creator source tree to .pluginspec files.

Rule {
    ...
    prepare: {
        var cmd = new JavaScriptCommand();
        cmd.description = "generating " + FileInfo.fileName(output.fileName);
        cmd.qtcreator_version = product.module.qtcreator_version;
        cmd.sourceCode = function() {
            var inf = new TextFile(input.fileName);
            var all = inf.readAll();
            all = all.replace(new RegExp('\\\$\\\$QTCREATOR_VERSION(?!\w)', 'g'), qtcreator_version);
            var file = new TextFile(output.fileName, TextFile.WriteOnly);
            file.write(all);
            file.close();
        }
        return cmd;
    }
}

Fast incremental builds

Qbs sees the project as whole and thus does not need to fork itself for subdirectories. Even if only a part of the project is built, the whole build graph is taken into consideration. The problems of recursive make (see [RMCH]) are no more.

This also has the consequence that incremental builds are much faster than with make. I have modified the benchmark generator script from [QPBS] and added qbs support. The following results were obtained from incremental builds of a project with 200 libraries, 50 classes per library, 30 lib-internal includes per file and 10 lib-external includes per file.

On my machine, doing an incremental build without any changed files with make takes

real 0m4.076s
user 0m2.556s
sys 0m1.952s

doing the same with qbs

real 0m0.843s
user 0m0.724s
sys 0m0.112s

Build Instructions

Enough talk. Where do I get it? How to build it?


git clone git://gitorious.org/qt-labs/qbs.git
cd qbs
qmake -r qbs.pro
make
make docs


Please read the docs, esp. the part “configuring qbs”. You can find them online here. Then you can start playing around with the example projects in qbs/tests/manual. If you are more in search of a real-world project, you can find qbs project files for Qt Creator right here.

The project is open for contributions. Please see “Setting up Gerrit” on the Qt Project’s wiki for instructions. The URL of the gerrit remote is <Gerrit/Jira username>@codereview.qt-project.org:qt-labs/qbs.
The project’s mailinglist can be found at http://lists.qt-project.org/mailman/listinfo/qbs

Outlook

The state of this project is experimental. It is meant as a playground for different build tool concepts. Qmake will still be around for a long time, and nobody will force you to use qbs or any other build tool – though of course we will probably try to push qbs for Qt’s own build system at some point.

Users of common meta build tools like CMake or the GNU Autotools may have noticed that a crucial part is missing if qbs is meant to seriously compete in the cross-platform build tool market: adapting to the host environment, aka configure checks. For the time being it is still necessary to use an external configure script to generate a JSON file for qbs’ use, but that is of course not meant to be the long-term solution. The idea is to make configure tests usable like other modules. Their implementation will of course not be purely declarative, but will contain some JavaScript code.

There is plenty to do! For a non-exhaustive list of ideas, see our issue tracker (once our admins configure public access to the product).

References

[RMCH] Peter Miller (1998), “Recursive Make Considered Harmful”, AUUGN Journal of AUUG Inc., 19(1), pp. 14-25
[TMQB] Marius Storm-Olsen (2009), “To make, or not to make – QMake and beyond”, http://labs.qt.nokia.com/2009/10/12/to-make-or-not-to-make-qmake-and-beyond/
[WNCM] http://lists.qt.nokia.com/pipermail/qt5-feedback/2011-June/000494.html
[QPBS] Noel Llopis (2005), “The Quest for the Perfect Build System”, http://gamesfromwithin.com/the-quest-for-the-perfect-build-system