Lars Knoll

Qt 5 Alpha

Published Tuesday April 3rd, 2012
107 Comments on Qt 5 Alpha
Posted in Qt | Tags:

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 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

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, 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 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 (, see also, 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

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.



Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Qt | Tags:


Excellent to have it finally out! This is an important step to get things done for the final in time.

MySchizoBuddy says:

what is the roadmap of creating web apps with QT backend. Javascript in the browser communicating with QT on the webserver. The use case will be engineering web apps which are compute heavy apps written in C++ running on a webserver.

Ben Bridgwater says:

Is Solaris/SPARC still supported (in the sense of will it build & work) for Qt 5.0 ?

anon says:

“The WebKit C++ APIs have not changed since Qt 4.x”

Ah – I thought I heard earlier that the move to out-of-process WebKit meant that the QtWebkit DOM API would disappear in Qt5. Is this not the case?

Adam Higerd says:

@MySchizoBuddy I wasn’t aware there were any first-party plans for this. There are a couple different third-party libraries that enable building web apps using Qt on the backend; one of those is QxtWeb, and I hope it doesn’t seem too brazen for me to plug it considering I wrote it. (But I have to give a lot of credit to Dee Holtsclaw and Arvid Picciani; QxtWeb wouldn’t be where it is today without those two helping me.)

Volker Hilsheimer says:

Congratulations Qt Community!

@anon: The WebKit1 APIs aren’t going away (at least, yet), but they do lack an active maintainer, which may mean they might break/etc over time due to churn upstream in WebKit.

Lunarcloud says:

Are the qml desktop components going to become standard?

I’d love to use them and not worry about support and weird compiling on different platforms.

Davide Spada says:

While I am happy and excited hearing this new alpha release, I’m still too inexperienced to comment about.
But, reading the linked and the present blog post, I’m wondering why JavaScript should be better than C++, and moreover what will Desktop application development be in the future with Qt 5.
I’m currently studying both C++ and Qt for the solely purpose of developing cross platform desktop application not being dependent upon Micro$oft .Net environment. Do you think it is still a good idea? Which benefit will I enjoy in the future?

By the way, I big thanks to all the community developer!!

MySchizoBuddy says:

@Adam Higerd thanks for letting me know about your project. I’ll check it out. Is it a hobby project or something you are going to develop full time?

Adam Higerd says:

@MySchizoBuddy I had originally built it for my previous job and open-sourced the code; it’s still in production use with a few thousand deployed units. I’m only maintaining it as a hobby right now because my job has moved on, but Dee Holtsclaw has been doing a lot with it and has provided a lot of bugfixes and a few features. If you want to discuss it more, you can drop into #qxt on Freenode IRC; I don’t see much sense in cluttering up this comment thread with it.

Stephen Chu says:

What’s the status of using QML to develop desktop application? i.e. replacing QWidgets with QML elements in OS X and Windows?

Scorp1us says:

I second @Lunarcloud’s concern.

Adam Higerd says:

@Lunarcloud, @Scorp1us: The party line I’ve heard so far is to look for it in Qt 5.1, but it won’t be in 5.0 yet.

charley says:

Great announcement. Small nit: “Four big architectural changes”, item 3, ends with “Link to overview of modules”. — I think you intended a hyperlink here?

spud says:

Looks exciting!
So, is perl a requirement on Windows now?

Scorp1us says:

@MySchizoBuddy youmight also want to look into Wt (aka witty)

snowpong says:


If is really all that is needed to move from 4 to 5 I’m impressed!

smoggy says:

Thanks for this epic effort.

Guys i’m having a problem compiling in windows 7. The following error appears twice at least.
I have qtsdk package instaled and also a recent version of qt creator and qt 4.8 .

tmpmocrelease_sharedmoc_qmlapplicationviewer.cpp(10) : fatal error C1083: Can
not open include file: ‘../../../../../../../helper/qmlapplicationviewer/qmlapplicationviewer.h’: No such file or directory
cd cppextensions && C:QtSDKqtcreatorbinjom.exe -nologo -j 2 -f Make

By the way why not replace perl + python with cmake and in the process deprecate/bury qmake.

ary says:


I don’t see why it would, because Qt 5 doesn’t actually use Perl for evaluating regular expressions, it merely uses a Perl *compatible* regex engine, i.e. one that supports the advanced regular expression syntax also used by Perl.

The old QRegExp class of Qt 4 also used more or less the same regex flavor, but with many syntax limitations and idiosyncrasies (akaik), and it was *very* slow compared to other regex engines in use today (it ways developed in-house for the Qt project, but apparently not many resources were put into improving and maintaining it).

The new QRegularExpression class of Qt 5 uses PCRE ( internally, a very small C cross-platform library which is already used in many other projects (including e.g. the Apache web server). Afaik a copy of the library is shipped with Qt itself, so there are no need to install additional dependencies.

Also, according to recent discussions in the qt-devel mailing list, the old QRegExp class will only be deprecated but stay available in Qt 5 core for compatibility reasons, due to the slight behavior differences I mentioned above. But I suspect that anyone doing any serous regex work in their Qt application will want to port it to the new QRegularExpression class as soon as possible, as it’s more powerful and *MUCH* faster.

David says:

On Latest release of Kubuntu 11.10 (32bit) Then do a standard make. Which fails inside svn.
make[1]: Entering directory `/home/david/qt/qt-everywhere-opensource-src-5.0.0/qtsvg’
cd src/ && /home/david/qt/qt-everywhere-opensource-src-5.0.0/qtbase/bin/qmake /home/david/qt/qt-everywhere-opensource-src-5.0.0/qtsvg/src/ -o Makefile
Could not find mkspecs for your QMAKESPEC(default) after trying:
make[1]: *** [src/Makefile] Error 3

Any suggestions for a work around

Jason says:

Builds fine on Fedora 16, takes about 1hr (30mins for webkit).
Note that if you watch the output of ./configure you will see it lists which options are enabled in the build. I was missing pulseaudio, gstreamer and most important opengl (which is v important in qt5) so I recommend you install:
mesa-libGL-devel alsa-lib-devel pulseaudio-libs-devel gstreamer-devel gstreamer-plugins-base-devel gstreamer-plugins-* gperf mesa-libEGL-devel libXrender-devel libicu-devel libudev-devel libxcb-devel
You may need to install others so check what ./configure says. It is worth doing to enjoy the multimedia and map examples, also GL support is vital for speed to get a correct impression of qt5 vs qt4. Great work girls&guys!!

Marvin says:

Is it possible to get a build containing webkit for Windows (VS2008)? Have tried to compile from the repos before, but as it is commented here: “Compilation is currently disabled on Windows for this alpha, as building it right now is rather complex.”, and webkit is quite essential.

Anton says:

Not sure if this is the right place to ask but ayway – are there any plans for incorporating Scintilla or similar? In other words, if I would like to write cross-platform code editor, is Qt5 going to help me?

Jason says:

Is anyone else having problems running the qmlvideofx example? It will not run due to “plugin cannot be loaded for module “Qt.labs.folderlistmodel”: Unknown error”. I know it finds the plugin ok (set QML_IMPORT_TRACE to see this) so the only immediate strange thing I can see is that the plugin links to not

Natone says:

@Anton: There is QScintilla already. Why do you want to see that wheel re-invented?

Kevin Kofler says:

Rumors are Qt 5 Alpha doesn’t support style plugins nor platform plugins, is that true? If yes, when is that going to be fixed? Those features are essential for desktop integration!

Jason says:

Just FYI if others had the same qmlvideofx problem as me I solved it by:
> cd qtdeclarative/src/imports/folderlistmodel
> make clean
> make
It seems that two modules, namely qtquick1 and qtdeclarative, build and try to install a folderlistmodel plugin to the same import location. Qtquick1 wins and so if you try to run the qmlvideofx example it will fail as it is expecting a qtquick 2.0 (qtdeclarative) plugin not a qtquick1 one. Hope it is working out of the box for the beta as it’s a cool demo to show people.

Ruchee says:

Good Job! Thx

Mika Hanhijärvi says:

I still don’t like this at all because Symbian wont get Qt5. That makes Qt5, and all versions after that, totally usseless for me 😛 And no. don’t say “you can develop for the desktop” etc, I’m not interested and I don’t even have time for that because mobile devices are my main yarget. I personally wish Qt was never moved to open governance if this is the result of it. Those of us who are developing for the Symbian will lack all the goodies of Qt6 and that makes reading these news really frustrating, and that makes me angry.

Mika Hanhijärvi says:

Typo fix;

* Qt6 == Qt5
* yarget == target

Marius Storm-Olsen says:

@Smoggy: I think your installed SDK, creator, and Qt 4.8 might be interfering in your build process. Try to ensure those are not in your path when building Qt 5.0 alpha.

@Spud: Yes, to build Qt from sources you need Perl, Python, Bison, Flex and gperf. On Windows, those last three tools are included in the package under gnuwin32/bin (which the build script will set up automatically for you). For the first two, just install Active(Perl|Python), for example.

@David: You are not following the supported build process. Did you read the packaged README, or at least ? You’re supposed to use the build script, not a top-level make.


@Kevin: QtWidget still uses styles, and we use even more platform plugins now, since all platforms are using the QPA framework 🙂

@Jason: Ah! Good to know, thanks! Please create a bug report for that, so we can get that fixed.

@Mika: Symbian was not going to move over to Qt 5 anyways, so the code was just bitrotting. Also, due to the move over to the QPA plugin system, it would be a major effort in porting. However, if someone out there has a huge wish for supporting it and spending the effort in creating the needed QPA platform plugins for Symbian, and supporting them, I don’t see why it couldn’t be done? However, I’m pretty sure Nokia will not be doing it.

foo says:

Will Qt 5 work on systems that do not support hardware accelleration or do not have free software drivers to support that?

Philippe says:

Do you have a rough estimate of a planned release date? I have to release a product in about 6-7 months, and I only want to spend time with Qt 5 (even alpha), if I am sure I can use it at the end.

Anton says:

@Natone, @Marius Storm-Olsen,

thanks for the replies. Yes, I know about QScintilla. But:

From their page: “QScintilla2 supports both Qt v3 and Qt v4”.

Also, and sorry maybe I misunderstood, I thought since it is from Riverbank I cannot use it with Qt from Nokia. But maybe I’m horribly wrong? Is the only difference the license? In another words, should I read your relies in a way that QScintilla eventually will get Qt5 support and until I’m ok with their license I can write the cross-platform editor?

Dmitriy Vilkov says:

Great work guys! Keep going – you are the best!

erdem says:

Great News!
Thanks to everybody who contribute to the mighty Qt.

The most important part for me is to have full continuation of “C++” support and development inside this new major release.

Rupert says:

@smoggy: One reason not to bury qmake is that we all know I would dig it back up again and make sweet sweet love to the corpse.

I don’t know cmake, and until I see qmake displaced via merit, rather than the forked tongues of zealous nitwits, I am personally gonna dwell on this old girl in her dotage.

Konstantin Tokarev says:

>The platform dependent backends using X11 or CoreGraphics are gone.

That’s a pity. Qt Creator performs much better over NX with -graphicssystem native than with raster, and looks better.

Marvin says:

… or possibly know the rather complex build procedure for Qt5 on Windows?

A. Southcape says:

Ubersome! Don’t stop there, world changes quickly these days. Maybe Qt might benefit quicker development cycle too.

Max says:

For those who have problem to build Qt 5 under Unix with that instruduction:

If you fail to build QtWidget the you have to install “sudo apt-get install libglu1-mesa-dev”


smoggy says:

I guess build systems like qmake or cmake are a sort of vim vs emacs (Vim is better).
But would really like to see QT adopt more tools from other sources, there used to be a “not built here” do not touch attitude. I guess the modularity of QT will change that. More adoptions without the problems of including it in the main packages to create bloat.

By the way learning new stuff is better than making sweet love to good old dusty MS Dos kind of stuff like qmake 😛
I remember a recent episode where there was some contest with programming challenges and some guy picked cmake as programming language to solve go on the contest. Try doing that with qmake.

Adam Higerd says:


Challenge Accepted.

What do you want me to do in qmake? 😉

Tom says:

Sigh. I like Qt because I understand C++ and how it fits with Qt. Now I have to learn a completely different language to write Qt5 programs? Not gonna happen. My main suggestion: Change the name to remove the “Qt” prefix.

Fonzi says:

It’s exciting to see all the additions and improvements that are being made for Qt. 🙂

I do have one question though regarding visual QML items that are implemented in C++. In the article the following is mentioned:

“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.”

Could someone elaborate on how this affects the implementation of C++-based visual QML elements? So far I’ve been deriving from QDeclarativeItem and overriding the virtual paint method. I could not find a corresponding method for QQuickItem in the Qt 5.0 documentation. What’s the basic approach to drawing custom items in QML in Qt 5.0 (without using the Canvas element)? If not QPainter, what API is used? If anyone has a link to more detailed information on this topic I’d greatly appreciate it. 🙂

Jeremy Friesner says:

Hmm, I’m trying to compile my Qt 4 program against Qt 5 (just to see how it goes), and I’ve come across this issue: Qt 4 likes me to include files like this:


… but Qt 5 likes me to include this:


… which is fine if I want to compile for just one version of Qt or the other, but what if I want to have code that compile against both Qt 4.8 *and* Qt 5.x? Am I going to have to do a

#if QT_VERSION > 0x050000

for every single one of my QWidget includes? Or should the version work in both cases? (in which case, why is it not working for me under Qt 5?)

smoothio says:

I think you want QQuickPaintedItem

Ben Bridgwater says:

Are there any instructions on how to build the X11 QPA plugin?

I’m trying to build Qt5 for Solaris and it seems there’s no easy way to get XCB support (I’ve got libxcb, libxcb_devel, libxrender, libxrender_devel installed via pkg-get from, but evidently that’s insufficient to meet the XCB dependencies since ./configure says the XCB test failed, and I can’t find Solaris equivalents to the other Linux XCB package dependencies).

My understanding is that I could get a working (incl. GUI) Solaris Qt5 build using X11 (vs XCB) by first bulding it with -no-xcb and -no-wayland, then building the XCB X11 plugin afterwards, hence the question.


Fonzi says:

@smoothio: I took a look at QQuickPaintedItem but the docs state that

“QQuickPaintedItem is meant to make it easier to port old code that is using the QPainter API to the QML Scene Graph API and it should be used only for that purpose.”

For my purposes, I’m interesting in knowing what the new/recommended way of creating a C++-based visual QML element is (no concern for supporting legacy code). Is there a doc that explains this or are there plans to create one? I think this would be very helpful, as I haven’t found any information on this in the API docs so far.

Jeremy Friesner says:

Gah, the web form ate my angle-brackets. Here’s a (hopefully corrected) repost:

Hmm, I’m trying to compile my Qt 4 program against Qt 5 (just to see how it goes), and I’ve come across this issue: Qt 4 likes me to include files like this:

#include <QLabel>

… but Qt 5 seems to require that I do this instead:

#include <QtWidgets/QLabel>

… which is fine if I want to compile for just one version of Qt or the other, but what if I want to have code that compile against both Qt 4.8 *and* Qt 5.x? Am I going to have to do a

#if QT_VERSION > 0×050000

for every single one of my QWidget includes? Or should the version work in both cases? (in which case, why is it not working for me under Qt 5?)

Dian says:

I really don’t get it – why all the efforts to turn a wonderful C++ framework into yet another slow, interpreted language API, of which we already have too many? I mean sure, the C++ API is still there, but it doesn’t seem like any significant development efforts is being dedicated to it.

Sure, QML is good for prototyping, but those same components and prototyping concept could have been created for the C++ api just as well, which to me seems to be deliberately left behind from supporting touch and other contemporary features. Writing QML components in C++ IS NOT EASY, it is a tedious and complex process which actually takes more time than achieving the same functionality in C++ alone. And what is worse, it relies even more on code, generated by the MOC, taking developers further away from knowing what is actually going on, which in my book is a bad thing.

Qt has made its name for being a good C++ framework, and I really dislike the direction it is not taken but being forced into ever since Nokia bought it. It becomes less and less about serious and performing software, and turns more and more into another eye candy, toy app framework, which is a pity. I’ve had this bad feeling ever since the buyout and despite the many reassurances from trolls, my worst fears are gradually coming to life, disguised as the best thing since sliced bread. I don’t have a problem with QML coexisting with the C++ API, but wasting all development efforts on this toy app API is wrong and a knife in the back of the C++ developers who promoted Qt over the years and spent time mastering what is not deliberately pushed to become obsolete without any reasonable need for this.

And what is the worst part – there is no feasible alternative to Qt, which is why Nokia can afford to do whatever it wants without fearing the consequences, there is no other C++ framework comparable to Qt, we have no choice, either being forced into QML direction, or leaving it for some other sub-optimal API. It is a pity, every time people make something good, some greedy company snatches it and spoils it… When I started using Qt 3 years ago, I was very optimistic and really inspired, day after day I fell more and more like I have wasted my time and I need to go some other direction, I cannot shake the feeling of being betrayed.

@Tom: No. If you don’t want things to change, then don’t change them. Qt 4 applications will [mostly; with some small changes] run just fine with Qt 5, hopefully better and faster due to optimisations in the underlying stack. That won’t be going away anytime soon, but on the other hand, we hope that you’ll over time experiment with the other technologies available to you as they mature more.

@Jeremy: #include will work just fine if your buildsystem is setting include paths correctly. It works fine using qmake, at the least, and large swathes of the Qt source uses includes just like that 🙂

@Ben: there is no x11 plugin. There’s only xcb. To find out why the configure test is failing, run configure with -v.

Adam Higerd says:

@Dian: I don’t like QML much either, but the performance argument is invalid. The whole point of declarative is to use the interpreted language once and then get the heck out of the way. This actually makes it FASTER (after startup is complete) rather than slower as the backend is free to optimize the configuration in ways it wouldn’t do if you were explicitly setting everything up.

The fact of the matter is that QWidget is slow and bulky already, and Qt Quick is just that — quick. I’ll have to just bite the bullet and get used to using Javascript for the glue between high-performance C++ layers, because the fact is that it IS going to be a superior solution… IN THE LONG RUN.

It’s not there yet, and that’s what upsets ME. Qt 5.0 is being pushed through when there’s no supported replacement for QWidget and friends. Qt Quick is great for making customized UIs with high-performance graphics, but if you need to integrate with the desktop you’re stuck using the lame-duck minimally-supported lower-performance QtWidgets module. They say Qt5 is the future, but it can’t even keep up with the present.

… oh goodness.

I just realized I’m making the same arguments about Qt5 as a Qt4 user that the Qt3 users were making about Qt4 when it was released, and I was on the side arguing that people should move to Qt4.

Chris says:

Any plans on making Qt aware of the STL? STL is superior compared to QTL. Perhaps add a build option so that where-ever a Qt function returns/expects a Qt container it would now switch to use an STL container. I find it frustrating that Qt completely ignores the C++ standard library.

Jeremy Friesner says:

@Robin Thanks… I figured out the #include problem, it was that I had QTDIR was set to point to my qt-everywhere-opensource-src-5.0.0 directory, but for Qt 5.0 it needs to point to qt-everywhere-opensource-src-5.0.0/qtbase instead. That’s different from how QTDIR worked in all previous Qt versions, and I didn’t read the instructions carefully enough ;^)

Adam Higerd says:

@Chris I don’t know where you get that STL is superior to Tulip (Qt’s template library). Tulip’s containers are more expressive and have optimized a number of common use cases, and Qt’s data structures mostly are compatible with std:: algorithms and most functions in support STL data structures. Qt doesn’t ignore STL; it just chooses not to use its containers because it’s far more efficient NOT to use the STL containers — faster compile times and implicit copy-on-write sharing.

Adam Higerd says:

Erf. Most functions in qalgorithms.h / QtAlgorithms.

Dian says:

@Adam – sure, QtGui is bloated, many of Qt’s APIs are bloated beyond necessity to be honest, but considering QML is mostly C++ underneath, those same lightweight components could have been made available through the C++ API. Qt Quick 2 might be fast, but in a very narrow area, if you draw the same elements a.k.a toy app that substitutes a website people are too lazy to type the name of in a browser. When you get to complex drawing of unique elements with painter state changes the new scenegraph offers no actual benefit with the exception to the multithreaded animation/blitting approach, which too could have easily made a part of the C++ api. The same type of performance boost Qt Quick 2 is enjoying is achievable for GL widgets as long as you optimize your rendering pipeline, minimize painter state changes and all that obvious stuff every programmer should know.

JavaScript is orders of magnitude slower than native code, so your argument cannot possibly hold value. Qt makes C++ easy and not cumbersome at all, it is not like using the STL, having to reinvent the wheel or anything like that. QML is not that much easier and faster to develop to justify the performance and efficiency hit.

I find stock QWidgets pretty lame, hate the “native” look and feel and I pretty much invent my components from scratch, the same type of highly custom UI is entirely possible in C++, and QWidgets are by no means slower than QML, and in fact custom UI components made with QWidget perform significantly faster than custom components made in QML, as well as custom QWidget components take significantly less time to create than QML components in C++ and the usage is simpler, you just use them without pages of glue code…

If you are one of those toy app developers that race into coding less and less usable and productive apps, then I get your motivation, but with the direction Qt is being pushed it becomes less attractive for developing useful, powerful and productive programs. Nowadays the standards for what passes for an “app” are dropping like crazy, the majority of “apps” written today are nothing but website substitutes, including most of the QML projects I’ve seen, if you want to go serious with QML you will actually have an easier time using the C++ api alone and not even waste your time on gluing your C++ logic to be used through QML, and I hate the fact Qt is being pushed to become harder and less usable as a low level, power and performance API at the expense of becoming a good API for useless toy apps.

Just my 2 cents thou, don’t let those get in the way of that “amazing progress”…

Dian says:

As I said, I have no problems with QML itself, in fact I find it useful and neat in some of the cases it is applicable, my problem is that QML is changing Qt, it is literally hurting the more efficient, productive and powerful aspects of Qt, it takes development priority focus away, it pushes the C++ api to become obsolete or at best harder to use. Sure, you can use C++ through QML but it is a pain in the ass compared to … just using C++, and I hate Nokia with a passion for trying to make C++ development only obsolete and push the C++ api to only be used to extend QML. This is in full conflict with all the reassurances from trolls that the C++ api is not going anywhere, and I am not being paranoid or making this stuff up, it is stated in this very blog:

“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.”

And don’t feed me the nonsense “QML does not harm C++” – if all the development effort invested in QML was put into modernizing the C++ API Qt would have been even more powerful and flexible today. There is a subtle difference between “still being able to use C++” and “having an up-to-date, flexible and powerful C++ API”

Dian says:

I mean… just look at the LAB entries – HOW MANY pages you have to go back to find something new and neat being done for the C++ api? Apart from adding minor C++11 feature support for Creator, most of which don’t even work with the ANCIENT version of GCC the SDK ships with, you will probably get bored from clicking the Previous Entries link long before you find any significant contribution to the C++ api. Oh no, Qt Quick ain’t changing nor hurting Qt, a C++ framework, not hurting it at all. Nor is water wet, nor Earth revolving around its axis and the sun, it’s just mad talk…

Adam Higerd says:

It all depends on your usage patterns. When it comes to stock components, QWidget is slower than QGraphicsView, especially as you scale up — QWidget performance suffers more as you increase the number of widgets. Custom components may be a different story but I think that’s only a matter of time, since best practices for custom QML components haven’t really been ironed out yet as far as I can tell. After all, even the Qt Quick components have to have an implementation; there’s no magical benefit to being part of the Qt source code.

I agree that it would be nice to be able to use Qt Quick features from C++. I was going to say that in my previous post, but what I realized is that a declarative setup means that it doesn’t actually make a difference. I can deal with having to use an interpreted language as glue code as long as it stays out of the critical path. If I can define my slots in C++, I will suck it up and connect my components together in Javascript if that’s the optimal solution. If I CAN’T control the UI afterward from C++ code, then I’ll be right beside you in complaining. And yes, this includes instantiating a thousand widgets in a loop if that’s what my needs demand.

You say the native look sucks, but I’m a Mac user. Looking native is a lot more important to me than it is to Windows users. (Because I’ll agree: the stock Windows components look atrocious and even Microsoft doesn’t use them.) If I don’t at least put on a show of acknowledging the Apple HIG, the app is just going to feel out of place. And I like coding in Qt a ton better than I like working in Cocoa, so I end up writing apps in Qt even if they’re never going to be used on Linux or Windows.

Adam Higerd says:

Meanwhile, I stopped worrying about Nokia’s direction, because this is open-source software. If I want Qt to do something, I make it happen. That’s why I started the Qxt project. And most of Qxt is going to be reasonably portable to Qt5 when the time comes to make it happen.

But saying that Nokia hasn’t done anything with the C++ APIs is bunk anyway. Maybe you haven’t seen it on the front end, but I’ve been seeing “FIXME: Qt5” comments in the Qt source code since around 4.2. It’s not marvelous new technologies being given to us, but it’s still evolutionary improvements to how we write C++ code. APIs are being more consistent. Ugly awkward stuff is getting thrown out and (eventually) we’re going to get something even better for it. I don’t expect Qt5 to really prove itself until around 5.2; that’s how long it took Qt4 to really catch up to full feature parity with Qt3.

So again: If Qt5 ISN’T an improvement over Qt4 for C++ developers, I’ll be right beside you complaining. But so far I see no reason to say that Qt5 (barring specific issues like being released with no replacement for large swaths of deprecated content — but at least this time we’ll still have the deprecated content instead of having to go without like the 3-to-4 transition) won’t be an incremental improvement over Qt4. Maybe for C++ programmers it’ll basically be Qt 4.9. I say, who cares if it’s Qt 4.9 with a different number on it? As long as I can be confident that my tools are going to be well-supported, I don’t mind that there’s no fancy, hyped new technology for my preferred use case.

David says:

Anyone know where the QML desktop components are being developed for QT5? Is there a git repo I can follow to see how progress is coming along? Has a release window been defined like (5.0 beta, or 5.1)?

Tomn says:

Please, take into account (Mac) OS X Lion new stuffs like Full-screen mode (this feature would be at least great in my case).
And for the future OS X Mountain Lion: the Notification Center.

There are also sandboxing and genuine apps (Gatekeeper), pop-ups widgets (like the download window in Safari or on the iPad), auto-save/Versions (currently when the program crashed we have a useless Restore dialog), sharing button (Tweeter, Facebook, Mail, …), AppStore/GameCenter, … If Qt could help to integrate some of those functions.

And I’m curious to know how Qt would react to new Windows 8 Metro interface.

Adam Higerd says:

@tomn: Qt has supported fullscreen mode for a very long time; QWidget::showFullScreen(). A lot of the other stuff you’re describing can be included using native libraries and aren’t really cross-platform features, or are probably a little bit out of scope for the core Qt libraries.

Dian says:

@Adam – there are a few “little” facts that you seem to keep on deliberately missing and those are:

All the QML candy is made possible by a C++ back end, to which Nokia is deliberately offering no C++ front end to use natively. This aims to create an artificial technological advantage for QML by handicapping the capabilities of the C++ API. All the “innovation” that QML enjoys could very easily be exposed to C++ developers, but that is not the case, and the only logical reason to do so is to cripple the high level capabilities of the C++ API and make it uglier and less attractive to developers.

C++ is an ISO standard, there are TONS of powerful libraries out there you can natively use with C++ with unprecedented performance and efficiency. QML is a proprietary technology, the mastery of which opens ONE SINGLE DOOR, which is quite inferior to C++ which opens countless wide gates of possibility.

C++ is the most flexible and powerful programming language out there, QML is simple and that is easy, but I don’t really see this as an advantage over C++ – you can keep it simple with C++ as well, with a complete API you can be a fully proficient developer by keeping to 1% of the C++ standard without even touching complex features, you can instantiate objects, you can modify properties, you can invoke methods – all the stuff QML can, only much faster and much more efficiently. And with C++, unlike QML, you can go deep and complex, if you so choose, C++ offers the full range of options, basic programming, generics, procedural programming, OOP, template meta-programming, unprecedented inheritance… plus the option to easily hook your code to virtually every good API in existence.

As of why exactly does Nokia push to cripple the C++ API and push it in the complex low level corner, so it can promote its own proprietary standard – I honestly cannot tell. My bet is it is the same reason the ENTIRE industry is doing the same thing, everyone pushes developers away from C++ and forces them to adopt some limited use, poor performance and efficiency, proprietary language, and I see absolutely no logic or reason behind this decision, and it makes perfect sense, since the industry long abandoned logic and reason in pursuit of more “materialistic” aspirations, which have little to do with developer or end user benefits.

You are right thou – Qt is an open standard, and you are free to implement stuff it lacks, HOWEVER you cannot possibly compare a few custom widgets to a complex rendering back end. I’ve done plenty of custom widgets myself, but I am a single developer, I do not have the capacity to fill those huge voids Nokia deliberately leaves in the C++ API, nor can you. Nokia is in control of the trolls – the main moving force behind Qt, and exploits their efforts to push developers away from C++, which I truly despise, I like C++, I don’t find it hard, nor complex, I like the power, the flexibility and the performance, in those aspects QML cannot ever come even close, I don’t want to bother with QML, I chose Qt BECAUSE OF C++, and I simply cannot be happy about Nokia pushing to render obsolete all the efforts I dedicated to it. And sure, I am still free to stick with C++, if I chose to miss out on all the good features they deliberately do not open doors through the C++ API, and if I have to do everything myself, they why even bother with Qt?

Adam Higerd says:

@Dian: I’m not missing the point at all. My point is that there is no point to using QML from a C++ front end. It would garner no technical benefit over the JS frontend, as the whole point of a declarative API is to express things up front and then get out of the way. This means that the only benefit that a C++ frontend would provide is the ability to write the code in C++ instead of JS. And at that point, C++ support becomes a *wart*. It means that Nokia would have to maintain two separate front-end APIs, make sure that they’re always at feature parity with each other, deal with twice as much surface area for potential bugs, et cetera. The only people who would be happier about it are the people who religiously shout “up with C++! down with interpreted languages!” without regard for what that actually means.

So what I’m saying is that even though I would be HAPPIER with a C++ API, not having one isn’t a deal-breaker for me because not having one means that the API that *is* provided is going to be better supported. And it’s not like I can’t write C++ applications with QML. I just have to include some JS fragments for setting up the user interface. You seem to be implying that QML means that the entire application will have to be written in JS; this is false.

If Nokia had given themselves a back-door C++ API that would let them write Qt Quick applications without writing a scrap of JS, then again, I’d be standing right beside you complaining. But they haven’t done this and they are certainly going to eat their own dogfood when the time comes to release Qt Quick-based applications. (But even Nokia will be sticking with QtWidgets for Creator.)

As for the rest of your post, it’s based on a faulty assumption that C++ is being pushed to a second-class citizen, and it’s not. It’s also based on the concept of QML being a “proprietary standard”, and yet you’re completely OK with the fact that Qt is exactly as proprietary as QML, no more and no less. And neither Qt nor QML are really a “standard” anyway except inasmuch as Qt is part of the LSB. They’re just libraries, not standards. You’re going to be able to write a program and implement the entire thing in C++ with the exception of a small amount of glue code for defining the user interface layout. This was already the case with QtWidgets and generating a small amount of XML for the same purpose, except with QtWidgets that was optional, so it should be pretty plain to see that you have lost no expressiveness because it’s the same concept.

As an aside: Javascript is an ISO standard too — ISO 16262 — and has seen much more innovation and improvement in the last few years than C++ has, and while there might be MORE libraries available for C++ there are still a ton of mature, well-respected JS libraries out there. So your argument in that regard is wholly invalid. And this is coming from someone who agrees with you that C++ is the best language currently out there!

Dian says:

No benefits from using the new stuff like the SceneGraph back end from C++? C++ offering no benefits over JS? What planet are you living on? Using QML from C++? What you say makes ZERO sense, I am not talking about using QML through C++, this is moronic, I am talking about using the C++ back end behind QML natively with C++, which actually makes sense.

Nokia go even further than pushing C++ to become a second class citizen – none of the most significant innovations in Qt5 is accessible through the C++ API. Nokia, like many other big corporations are pushing to make C++ the new assembly language, to be used only for low level stuff, passing through a mess of glue code instead of writing fully native C+ apps. Qt might be proprietary, but it uses a language that can be used with many other libraries, so if one day you decide to dump Qt you have a ton of options, if you go for QML and you dump Qt – then you have no option as QML is not supported by any other API out there.

I am amazed that you can be so blind to the fact Nokia has been developing Qt to offer features exclusive to QML, even thou the back end of all of those is C++, you say they cannot bother creating a C++ front end – well, it is a C++ back end, there is no effort in opening the doors to use those APIs natively through C++, other than Nokia shafting C++. Amazing to say the least, they use C++ to create APIs that push developers away from C++. It is not about having to bother creating a C++ front end, it is about simply exposing that functionality to be used natively, it is a matter of a simple decision, which Nokia is deliberately skipping on so they can force people who chose Qt for being a good C++ library to go for their own, proprietary and inferior language specification.

But hey, I honestly didn’t expect any better from an Apple fanboy. That “OMG, Mac OS GUI is so much better than the crappy Windows UI” gave you away…

Clemens says:

Hi guys,

i am trying to compile Qt5 on Windows7 with the newest MinGW (GCC 4.7.0) build from
Problem is, if configuring with “perl configure”, it stops with following error message:
(Changing the configuration options to perl configure has no effect.)

But it seems to be a problem with building qmake.. 🙁

Is this a general problem with GCC 4.7.0 on Windows? (Because if I configure it with MSVC 2010 it seems to work, also with the classic MinGW 4.6.2 from but i really want to use GCC 4.7.0 because some of the fancy C++11 stuff 😉

If anyone has a clue why this happens, I would be very grateful.

I also tried to modify the Makefile but this shouldn’t be necessary, should it??

Best regards,

Dian says:

C++ not being treated as a second class citizen? If all the new stuff available for QML was also available natively to use with C++, then I would agree. It is all C++ underneath the carpet anyway. No extra effort is needed to use a C++ back end through a C++ front end, all the extra effort is exposing the C++ back end to QML.

What Nokia SHOULD HAVE DONE is create all those new APIs, open them for native use and also offer QML as an alternative. But this is not the case, QML gets all those new APIs EXCLUSIVELY, even thou it would literally cost nothing to make it possible to use the APIs natively.

Nokia should treat all developers equally, then I would have no problems with QML. Sadly this is not the case. If you want to use all the recent innovations in Qt you are being forced to do it through QML, simply because there is no native access, or you can get stuck in time with the outdated and deliberately not modernized QtGui. If you really fail to grasp that concept, you definitely need to go back to school…

Clemens says:

Hi guys,

I have problems compiling Qt5 under Windows7 with the new GCC 4.7.0 (MinGW build from It stops after running “perl configure” with the following error message:
(Configuration options do not influence the error message, I am using Strawberry Perl, but using ActivePerl makes also no difference, Python is also installed, so there should be everything set up. Of course I added the compiler to the path variable.. but maybe I forgot something else..?)

With MSVC2010 and the old classic MinGW (GCC 4.6.2) from, it seems to work.
Why doesn’t it work with the new GCC 4.7 or with this mingw-build from “niXman”? Has anyone of you the same problem?

If anyone has a clue how I can fix this error in the qmake building step, please help me out.. i also tried to change the Makefile in the qmake subdir but should this really be necessary?

What else could I try to avoid this “No rule to make target xxx.o” with GCC 4.7 ?

Best regards,

Dian says:

And if I have to summarize it all in one sentence:

My problem is that in all the recent innovations in Qt the usage of QML is NOT OPTIONAL and using C++ IS NO LONGER AN OPTION.

You HAVE TO use QML as you cannot enjoy all those new features since there is no native C++ access to those. This sucks… It is nothing new thou, many companies invested money into creating new cool technologies using C++, but instead of allowing native access they use that to force developers to adopt their own proprietary, inferior alternatives…

Clemens says:

I have to add: I compiled Qt 4.8.1 successfully with the gcc 4.7.0 from mingw-builds. So, what’s different when building qmake in qt5, that could lead to this error? But only with GCC 4.7.0? At the moment, I am extremely confused, maybe someone can clarify this.. Thanks!

Lilo says:

I’d like to second the concerns voiced by Dian. I am using Qt for development of CAD applications on Linux. This might be a niche area but in many respects it is similar to development of other complex desktop applications based on C++ and Qt. As I understand there is (was?) a push to use Qt for development of mobile applications. This would explain QML. But, with recent developments, it appears that Qt is not going to be used for development of mobile applications anymore. So let’s look at the desktop side of it. For many (most?) desktop applications, I believe the following is true:

1) GUI is an important but secondary component. Most efforts go into design/implementation of the business logic/algorithms etc.
2) Most of the applications code and all data handling is implemented in C++
3) GUI needs to be aware of the application state, data etc.

Use of QML in this scenario has very significant disadvantages:

1) JavaScript can’t have direct access to application’s data. This necessitates development of a special software layer (special C++ API that JavaScript could consume). This is not something new. In CAD, historically, many applications use Tcl/Tk for GUI development. SWIG is often used to glue scripting layer (Tcl, Perl etc.) with C++. It works but it’s not a great solution. Besides, the reason for using Tk and scripting in CAD is fundamentally different from the reasoning behind QML. CAD applications often need to provide a way for the end user to customize and expand upon the standard GUI. That’s where scripting comes into play.

2) Back to Qt. Any “ease of implementation” advantages one can get from QML will be insignificant compared to the overhead that introduction of QML brings into development process:

* as mentioned above – communication between GUI (JavaScript) and application (C++) becomes an issue

* Some people are concerned that they would have to learn a new language – JavaScript. That’s not the real concern. JavaScript itself is a trivial language (a very small subset of OO languages like C++). However all development environments like QML (take Java for example) come with vast APIs. That’s where the major learning efforts are. For a desktop application where GUI is, say, 5% of total development efforts, expansive GUI APIs implemented in a different language introduce unacceptable overhead.

In general. I am concerned about Qt loosing it’s identity. It looks to me that it’s transitioning from being a great development framework for desktop applications to a mediocre development tool for not even clear what (mobile? web-centric tools?).

Acenes says:

I have similar concerns as Dian and Lilo. Nothing against QML, Qt Quick etc. it is was just an alternative to plain C++, but native C++ GUI is declared to becoma a second class citizen not further developed. An iherent C++ environment for business logig up tu GUI *WAS* actually the strength of Qt – before Qt5.

This seems similar to the downhill way Windows 8 is taking.

Marvin says:

@Dian: What you basically are asking for is a shadow implementation of all the QML _frontend_ cruft in C++ (something that isn’t really rational, as Adam tries to explain) in order to be able to use C++ to implement/[ab]use the same API’s made specifically for QML. The reason all these API’s are “exclusive” for QML is because they _are_ QML! Complaining that Nokia hasn’t “bothered” (or as you conspiratorially claim: “pushing C++ to become a second class citizen”), and moaning about Qt/Nokia/whomever “forcing” you to use JS in order to use QML does, IMHO, look rather silly. Neither Nokia, the Qt team nor anyone else is _forcing_ you to do anything, they’ve tried to create a new framework for rapid development, and if you for some personal reason don’t like it, so be it – don’t use it. And if you’d like to use C++ instead, there’s nothing stopping you from doing that (just quite a bit of work, and you might find yourself alone since it would be a fairly “suboptimal” codepath).

If you however do have some valuable, constructive input on how to improve things, please [ab]use the Open Governance framework Nokia so painstakingly have set up so that you (and others) can come with constructive feedback, ideas (etc) instead of trying to pick a trollfight in the release comments.

Now… for the other ting (sorry for being so insistent): Does anyone (inside or outside Nokia/Qt) have a working build (binary or hilariously complex build description) of QtWebkit for Windows?

Adam Higerd says:

@Marvin: I can try to help you troubleshoot the WebKit built process if you swing by; I’m actually due for building that again myself fairly soon. I have a build that’s a couple months old now from trunk built against Qt 4.8.0 using MSVC2010, and I know enough about the WebKit build process and source code that I may be able to help work through the problems, but something more interactive than blog comments might make it easier to help you.

Dian says:

@Marvin – so it is just a coincidence QML gets an up-to-date rendering back end while QtGui gets nothing? I never said anyone is stopping me from using C++, it is just a dilemma – stick to C++ and get stuck back in time, or use the updated APIs, which “accidentally” offer no way of being used natively. And Qt5 is just the beginning, it is not all that bad, it will only get worse, as Nokia seem committed to continue to isolate and push C++ in the low level, with extensive usage of code you don’t write but the MOC generates.

Heck, even Microsoft, the standard for a big and greedy corporation has enabled native C++ use of the new Metro graphics back end. It’s a pity that Metro is not cross platform, but if MS can open the door to their new graphics API, why would it be hard for Nokia to do the same?

What sucks is Nokia is pushing to render C++ a low level component extension language, by blocking native access to high level APIs. And if your application consists of 5 elements, as tedious as writing QML components in C++ and interfacing them to QML is, it is not that big of a deal, but when you have hundred custom components, it is simply not worth it bothering the effort to interface those to QML, it is MUCH EASIER, MUCH FASTER and MUCH MORE EFFICIENT to just use those natively, but then you are stuck with the age-old graphics back end. It is literally EXTORTION – adopt QML or miss out on all the benefits of like 90% of the development efforts invested in Qt.

And sure, some people say “everyone was bitching back during the transition from Qt3 to Qt4”, but that transition did not push the C++ APIs to get obsolete, Qt4 remained dedicated to C++, it did not impose a new programming language, Qt4 has been around for like 8 years, and QML only appeared recently, after the acquisition. Qt grew as a C++ framework, and now it is being forced (don’t tell me it is not) to become a QML framework you are only supposed to extend with C++ on the low level, with no C++ native access to all the nice, written in C++ APIs, accessible only through QML. Maybe Nokia’s inspiration is google, which did the same crappy job with the Android SDK/NDK, made GUI programming not accessible through the NKD, forcing developers to go through a tedious process of having to learn Java and interface C++ code to it. At least google uses a VM and has some security concerns, while Nokia is just exploiting the popularity of Qt as a C++ framework to toss developers into using its own, limited use, proprietary and inferior language…

I don’t say QML is bad, heck it has better syntax than most of the other atrocities the industry comes up with to “ease us” away form using C++, I just say it does not deserve all the focus and it is simply wrong for toy app QML to steal priority from C++, which made Qt the framework it is today.

21 says:

@Marvin – so it is just a coincidence QML gets an up-to-date rendering back end while QtGui gets nothing? I never said anyone is stopping me from using C++, it is just a dilemma – stick to C++ and get stuck back in time, or use the updated APIs, which “accidentally” offer no way of being used natively.

Heck, even Microsoft, the standard for a big and greedy corporation has enabled native C++ use of the new Metro graphics back end. It’s a pity that Metro is not cross platform, but if MS can open the door to their new graphics API, why would it be hard for Nokia to do the same?

What sucks is Nokia is pushing to render C++ a low level component extension language, by blocking native access to high level APIs. And if your application consists of 5 elements, as tedious as writing QML components in C++ and interfacing them to QML is, it is not that big of a deal, but when you have hundred custom components, it is simply not worth it bothering the effort to interface those to QML, it is MUCH EASIER, MUCH FASTER and MUCH MORE EFFICIENT to just use those natively, but then you are stuck with the age-old graphics back end. It is literally EXTORTION – adopt QML or miss out on all the benefits of like 90% of the development efforts invested in Qt.

And sure, some people say “everyone was bitching back during the transition from Qt3 to Qt4”, but that transition did not push the C++ APIs to get obsolete, Qt4 remained dedicated to C++, it did not impose a new programming language, Qt4 has been around for like 8 years, and QML only appeared recently, after the acquisition. Qt grew as a C++ framework, and now it is being forced (don’t tell me it is not) to become a QML framework you are only supposed to extend with C++ on the low level, with no C++ native access to all the nice, written in C++ APIs, accessible only through QML. Maybe Nokia’s inspiration is google, which did the same crappy job with the Android SDK/NDK, made GUI programming not accessible through the NKD, forcing developers to go through a tedious process of having to learn Java and interface C++ code to it. At least google uses a VM and has some security concerns, while Nokia is just exploiting the popularity of Qt as a C++ framework to toss developers into using its own, limited use, proprietary and inferior language…

I don’t say QML is bad, heck it has better syntax than most of the other atrocities the industry comes up with to “ease us” away form using C++, I just say it does not deserve all the focus and it is simply wrong for toy app QML to steal priority from C++, which made Qt the framework it is today.4

But don’t take my word for it, I IMPLORE you, go to the the main LABS page and start going back, and just note HOW MANY PAGES you have to go back to find the last time any significant innovation was contributed to the C++ API. It is all QML, all about QML, and it is not like the C++ API is perfect, needs no updating, no enhancing or anything like that, there is a whole world of possibilities to make the C++ API better but this simply does not happen, and why? Because all development efforts are being directed towards QML, and none of the benefits those efforts bring is available to improve on the aging C++ API, which Nokia seem to be quite happy to leave behind and make obsolete. And yet everyone is trying to convince us we are “still free to use C++” – heck, we are still free to use assembly language, but C++ is not assembly language, it is a full featured, portable and incredibly powerful and flexible language and it deserves to be the primary focus of Qt as it once used to be before Qt became a vessel to conform its developer base to the proprietary, limited use QML… C++ deserves to be the Qt programming language, not the QML extending language…

I really wonder what kind of Prozac people must be on to not notice or not be bothered by this “transformation”

Percy says:

I support Dian words with my soul.

I heard how some CEO/Manager’s (of companies that use Qt in its products) talk about how Nokia is hurting Qt and I see how they’re looking others technologies to face next years (and no, those technologies aren’t any of Qt 4.8 give nor any of Qt 5.x promises)

@Marvin: I don’t think that approach is good: “don’t like? then don’t use it” … I guess this is not the first time some Qt fan show those concerns, right?. As for your advise to use qt5-feedback, well that maillist is nearly frozen, all action is taking place on qt-project-dev where the devs are focus on release Qt 5 (wich is not a bad thing) … So, is easy to see that all the decisions (on regard those concerns) have already been taken, maybe there will be hope on Qt 5.x but I doubt it.

KarlNapf says:

I really do not understand all that fuss about qml/javascript.

Just look at the qml language: It is _declarative_ (“There is a button next to that other item over there”). That makes it in my mind more like the UI files than a Javascript appliciation… Yes, you can embed javascript into those files to express things like “Item A is 2 * somevariable pixels below item B”. Yes, you can do more complex stuff in js inside a QML file, but that does not make QML “javascript” to my eye. From my understanding QML is mostly a “UI files on steroids”. Those steroids are powerful enough to implement simple apps without any C++ at all? Great, I can’t wait to get my fingers on that!

Why is there such an outcry about having a more expressive way to describe UIs than the classic Qt Designer based one?

For those of us who want to cook up their own steroids having access to the Qt code behind QML would be nice, but how many developers do care to do so? Is that worth making maintenance of the code harder by making the apis public and thus harder to change due to compatibility guarantees that have to be made? How many people have bothered to look into the internals of “uic”? I for sure never did and I won’t bother with QML either;-)

To me this whole outcry over Qt Quick feels a lot like people complaining that UI files are using XML in favor of plain C++… On the other hand: Didn’t we have that XML discussion when Qt Designer was introduced back in the days?

Clemens says:

To the QML discussion: I guess, nobody has a problem with QML and the “declarative way” as long as the default Qt C++ way of creating desktop applications will not be discontinued. Maybe Nokia expects more money from the mobile phone area and therefore tries to concentrate the resources on the QML stuff, etc. but it would be a pity if all the nice C++ qt libraries become a backbone for QML only. If this is not the case, why bother?

To my problem: If there is nobody here at the blog who can help me compiling Qt on Windows with GCC 4.7.0 where should I go for help? IRC, mailinglists? Any suggestions or even better anybody an idea how to solve the problem? 😀

HollaDieWaldfee says:

Will the Qt-Desktop-Components a part of the final Qt 5.0 release?

To create a simple application in the native OS look in QML or porting an existing Qt-UI to QML is currently quite a pain.
Developing on mobile devices on the other hand with the native components is fun.

Adam Higerd says:

@HollaDieWaldfee: As I mentioned that in an earlier comment, the QML desktop components won’t be in 5.0 (here’s hoping for 5.1), although the current QWidget stuff will remain available in the QtWidgets module for the duration of Qt5.

rafael castillo says:

i would have loved that QML could be used to skin qwidgets components using scenegraph btw uic had a tool that allowed you to export the ui file to c++ in case you didnt want to use it.

i think ill check the internal of QML and qwidget maybe both can be glued somehow so you can access scenegraph from C++ and use QML for skinning qhich in my opinion would be much more interesting

Adam Higerd says:

@rafael castillo: QML isn’t a “skinning” language. It isn’t designed to modify a user interface. It’s designed to CREATE one. You should (if I’m not mistaken) be able to construct the UI with QML and then glue all of your C++ code to that fairly easily.

Now, if what you mean is to give the ability to change up the UI definition in the QML and then have the C++ code automatically use the new definition, that is exactly what it does.

rafael castillo says:

@Adam Higerd: is true i havent tried every corner of QML but is not like that as far as i tried at least, as far as i tried qwidgets or heavy custom c++ widgets(i mean complex nasty stuff that react to a zillion of events from the logic c++ core code) are aliens to QML and viceversa. sure if you move many of the logic to QML instead c++ is doable but the performance hit is too extreme to be acceptable.

so in this case i have a very complex widget that is threaded/SSE-AVX and react to many events/signals and depending on a nasty set combination it should display a lot of stuff in real time,etc and work perfectly on C++/qpainter which allow me to manipulate every aspect of the widget in realtime but i can’t find a way of remove the qpainter code and migrate it to QML keeping all the abilities i have now especially the realtime manipulation of graphics part of the widget, at least not whithout getting ugly in the QML side.

maybe is there a way and i just don’t see it but would be awesome to access scenegraph painter from C++ so i can get all the gpu accel goodies that QML from a qpainter like class without the massive rework(sure i can do some qopengl magic too but seems stupid isn’t it?)

sure for easy stuff like a plasma widget or simple apps qml and c++ are easy to use as far as i tried so far as long you don’t get too nasty (aka no heavy loop or fpu intensive drawing code since it seems i can’t simd or thread those in QML and the work the jit does is horrible in these cases could me tho pushing qml to do something is not designed for <– still learning)

MuldeR says:

There is a portability issue I ran into: Where has QPixmap::toWinHICON() gone?
The documentation does(!) mention it, but it has disappeared from the .h file in Qt5 Alpha release 🙁
My application eagerly needs this function! Please tell me: What do I miss?

Also: winId() seems to be of type quintptr instead of HWND now. Do I really need to reinterpret_cast all winId()’s now?

MuldeR says:

There is a portability issue I ran into: Where has QPixmap::toWinHICON() gone?
The documentation does(!) mention it, but it has disappeared from the .h file in Qt5 Alpha release 🙁
My application eagerly needs this function! Please tell me: What do I miss?

Also: winId() seems to be of type quintptr instead of HWND now. Do I really need to reinterpret_cast all winId()’s now?

Finally, how do I get rid of the “No platform plugin argument was specified” at startup?

MuldeR says:

Sorry, for double post. My first post didn’t show up first… 😮

Pyrrhula says:

I agree completely with Dian and Lilo. I work with flight simulation software myself, mostly on Linux, so it’s a bit similar to Lilo’s CAD software.

I worry that the Qt developers need to spend a lot more time to make QML as usable as the C++ widgets. This time could be spent improving the C++ widgets of Qt instead, that are used for proper desktop applications (such as QtCreator, which is brilliant). I can’t see why I would have to make my applications slower by running Javascript code in the GUI, just to use the latest Qt GUI features.

Also, I’m really don’t like that QT5 will require OpenGL to work. Not at all. It’s great as an option, but it should be possible to work without it. In my case, we have applications that need a consistent 3D performance, and I worry that Qt will start interfering with it for no good reason.

Miloskov says:

As a C++ developer I think now It is the right time to migrate to another C++ GUI API or create my own. Qt and Nokia folks are going insane with their QML and QtQuick. Qt now it is a QML API and looks that C++ is and after thought, It is sad because Qt was the best C++ GUI API of all times.

RIP C++/Qt.

Clemens says:

@Miloskov: What alternatives do we have? Any suggestions which are as usable from Windows as from Linux?
It is not necessary to incorporate all Qt features, only the GUI stuff. For the rest, I suggest Boost.
But what other GUI APIs are out there? GTK? WXWidgets? I am not convinced.. maybe we could fork Qt, if it turns out that Qt & Nokia really are insane. Or would this be a licensing issue?

A question to the lawyers or license experts: Is it allowed to fork a dual licensed project like Qt (only the GPL/LGPL part)?

Miloskov says:

@Clemens in that point you are right there are not good alternatives, the only way is maybe as you said fork Qt once and for all. MySQL is GPL and have a fork called MariaDB and looks it is legal. so I think we could fork Qt on the same license GPL/LGPL. I think I will ask at GNU for advice on that regard.

Also as you said we need just the GUI part, everything else with Boost, SQL libs and C++11 features is looking good.

Benoit says:

Thanks a lot for making such a great work! I am also looking forward to using QML components for desktop, making the GUI even faster to develop and much more powerful. That’s also good news for the future that the Qt technology is focused on graphics performance and makes real use of the hardware acceleration.

Regarding the C++ core functionalities, the new regular expression framework looks great. Any news regarding the “ItemViews-NG” research project? The Interview framework, while usable, is not as “intuitive” as we could expect it from a Qt framework. There is in my opinion a lot of room to improve the developer experience in that area.

MNaydenov says:

+ Better graphics performance (not proven for custom widgets and mid to large scale apps)
+ Separation b/w UI and Logic
+ No compilation time

– Slower startup (parsing the qml)
– Slower runtime (JS, Qt Properties for everything, everything is a Declarative Item, even “drawing primitives”, easy to abuse)
– Fatter (JS and JASON for every GUI app, note UI files ware optional. Also, Declarative drags many other modules as well, like Networking)
– Harder to implement custom widgets (compared to QGraphicsWidget and QWidget. Also, as of Qt Quick 1(2?) you can’t even subclass the provided components!)
– Harder and potentially slower to communicate b/w UI and Logic (glue code and new concepts, forced to use properties, tempting to do Logic in UI)
– Less control (widget creation, event handling, drawing, querying information, etc)

Rupert says:

@Clemens @Miloskov

Sure you can fork Qt; it does not matter how many licenses it has, fork it off the particular licensed version you want which is probably the LGPL version. Cheerio!

@Other people

c++ binary contracts bind our hands, hence the lack of a c++ API to scenegraph. If you want to create your own public c++ API for scenegraph, you should do so in a playground or as a Qt addon. There appears to be some interest in this functionality, although whether any of its proponents are prepared to contribute any labour other than tongue waggling/lashing is another story altogether. I would personally not want to be in that boat since cannibalism is a few short hours away from any dock. (You must be dealing with a maritime mofo when sailing analogies are perpetually afoot)


Clemens says:

@Rupert: Thanks for the information. It’s not that I want to fork Qt now, it’s kind of the last option (in my opinion). First, I’ll try to contribute to Qt itself.

What also settles my mind is this:

danny says:

I’ve been a C++ dev with Qt since 4.3 and I’ve been frustrated with the lack of development of the core C++ APIs. While the use of C++11 in Qt5 is welcome, there are soooo many bugs in Qt that are unlikely to fixed (particularly with stylesheets and mac-qt) while all the emphasis seems to be pushing a solution without a problem (Qt-Quick). I’m so used to hitting glitches and edge-cases in Qt now that I just #ifdef the code and use native-APIs to get the job done. That’s a big failure for a cross-platform framework.

“but also a path to a model where all UIs are being done in QML and Qt Quick”

Now this worries me. There is no such thing as ‘Quick Development’, only good programs and bad ones. The idea of non-developers and artists throwing together clumsy apps using custom widgets in a sluggish runtime sends chills down my spine. This isn’t the way to increase Qt adoption. And what is QML for? The (profitable) mobile space consists of three platforms right now; iOS, Android and (as a distant third), Microsoft. Not S40, or Maemo or Harmatten or any of those other devices that no-one care’s about.

And while Nokia wastes resources on these toys, the desktop is falling behind.

Dian above mentions that the C++ API is being made a second-class citizen. He’s absolutely right. There have been several blog post regarding features that should be part of the core API but which are not – for example native-looking toolbars on OSX which are only available via QML instead of the poor facsimile that unifiedTitleAndToolBarOnMac provides.

Yes you can work around if by using HiViews and .mm files but if I have to do that just to get a decent looking Qt app on OSX then I might as well just use Cocoa.

Also, 4.8.0 seemed to have all the hallmarks of a rushed release with MAJOR regressions. It didn’t even build out of the box on the Mac without errors.

And then you have show-stoppers like, sitting ‘In Progress’ in the tracker for 2.5 years.

I really, really hope this isn’t a sign of things to come.

Rupert says:

@danny: We need to get you in to see Nokia top management stat. Then you can convince them that 3 (it used to be 2, after it ceased to be ONE) toolkits/environments are all the phone market can bare. Then they can, after drinking of your wisdom for what surely must seem like an eternity (tastes like Gin), shut this turkey down and go back to focusing on Gumboots.

Heres a newsflash; Desktops aren’t Nokia’s primary concern, they are collateral damage that results from the need to facilitate mobile develop on any system and was a pleasant byproduct of purchasing Qt. There are Nokian’s already focused on getting Qt up and running on OS you would murder for; why don’t you chip in alongside them rather then calling for the gallows for them, which I assure you, would benefit no-one, least of all The Mothership.

Rupert says:


Very unflattering bug report, I agree. Be a dear and squish the issue so we can all move on.

7 says:

@Rupert – how is Nokia exactly focusing on mobile development without actually supporting any of the major mobile platforms? Qt has currently been cornered in the desktop area, and when Nokia are not concerned with the ONE THING Qt is – well, in that case we have an epic fail on the horizon, or is it just Nokia doing MS a favor by driving Qt, a major concern for their monopoly into the ground?

danny says:

@Rupert Interesting comment given Qt/Nokia’s schizophrenic PR since the Microsoft ‘partnership’. They’ve already bet the boat on Windows Phone and Microsoft’s tools which leaves Qt in limbo. Maemo was DOA, Symbian HAS been officially end-of-lifed, despite the recent push of a Java API for it (Java!).

They’ve already released a phone running Microsoft’s software. Where does Qt, even ‘Qt-Quick’ fit into that strategy? NO-ONE is using this stuff. But there are thousands of devs out their building commercial software, for the desktop using the C++ API.

I’m all for cleaning up the Qt API and for incorporating C++ features (in fact I think they should be more aggressive and REQUIRE a C++11 compiler for Qt5) but I just don’t ‘get’ the enthusiasm for QML.

blackfrog says:

Qt kicks butt in the embedded space. On limited hardware (no GPU), widget-based compositing works just fine. On a modern SOC w/ a GPU, Qt Quick is a light-weight alternative to Android.

Keep up the good work Qt Quick guys. Don’t let the nay-sayers drag you down.

Koh says:

@Jason thx, it works.

guoyi says:

when I use qt to send a web request to a web server. the url is a problem because javascript use unicode to describe url. but qt does not.

this means: if I use chinese in url. such as ‘郑’ , the unicode is %u5dde. the server side will accpet the url like : but qt is not able to send the url like that, it will send url like :

so the comunication will case errors.

is there any solution ?

thank you very much

Commenting closed.

Get started today with Qt Download now