Qt 5.0 Release Candidate

I’m very happy to announce that the first release candidate for Qt 5.0.0 has just been released.

Since the release of the second beta around 4 weeks ago we’ve made tremendous progress in stabilizing Qt and getting all the remaining pieces in place. While we have over the last couple of weeks fixed hundreds of bugs in the code base, most of the focus has actually been on polishing the usability of the product. The product structure and feature set is pretty much what we already have announced with the second beta. But apart from pure bug fixes there are still a couple of things that are new.

We have been completely restructuring the Qt documentation to make it easier to access. Please have a look and check out the new docs. We hope that they will make it easier to find your way and access the information you’re searching for.

The examples have also received a lot of love to make sure it is easy to get started with Qt. They can be easily accessed, build and launched from Qt Creator’s Welcome screen.

A final set of a few additional API changes has also made it into the release candidate. This release fixes the API set for Qt 5.0. Between now and the final release we will only make very minor adjustments to the API.

All of these change classes and methods that have been introduced with Qt 5.0, and with thus not affect you if you are porting your application from Qt 4. The list of changes from Qt 4 are described in the changelog. We have worked hard to keep that set of changes as small as possible so that it is very easy to bring your application over to Qt 5.

We are feeling confident that the release candidate is getting pretty close to the Qt 5.0 final release and would thus like to invite you all to give it a try. Please use the time now to report any issues you find back to us. There are a few bugs and problems we know about. You can find those at the known issues page.

We’re aiming to move towards a 5.0.0 final release as quickly as possible now. If we don’t hear about or find any large issues with the release candidate, we hope to be able to release it as 5.0.0 in about a week from now. Otherwise, we are aiming at fixing the bugs that show up and release a new RC in maybe a week from now.

With the restructured doc site, I can no longer use a web shortcut to get to the page of a class. I used e.g. “qt qwidget” to go to http://qt-project.org/doc/qt-4.8/qwidget.html and it would be nice to have it work in qt 5 docs, too.

Second, there are certain packages missing from the RC that were in the beta, such as Qt3D, QtLocation, etc. Are these packages deprecated or is there a separate place to get these from now? If so, can anyone give me a link? Thanks!

Those packages either (i) lack active maintainers, or (ii) are not of high enough quality yet. They are still available at http://qt.gitorious.org/qt and will be put into an official package (e.g. Qt 5.1) once they are are ready.

Is there a reason why you kept classes such as QGLWidget, QGLFormat without renaming them to QOpenGLWidget, QOpenGLFormat ? This is a little bit confusion since all other QGL* have been renamed to QOpenGL*

Thanks a lot, after a small but very happy experience with Qt 4.8 I’m getting all my (small) development team to adopt Qt starting with version 5.0. It’s a pleasure to see how much effort you’re putting on this work!

What is the problem your are having with retina? It should already work for native widgets (http://i.imgur.com/BOfHK.png) as well as QML in the final release. If this is not currently working for you, please report it as a bug.

Thanks Jens, In fact the code and widgets are sharp. I have a little concern about the icons in Qt Creator aren’t smooth. I would like to thanks all folks behind Qt 5.0 who delivered this great product as well.

It doesn’t PySide are jsut python wrappers to implement PyQt with LGPL licensing. Since then QML was started and moved to main focus. So PySide is kind of like an appendix. That being said, I still think Python+Qt is the best thing since English Muffins. But QML is just as cool. Given the momentum of QML, I’d focus on using that.

Thank you for keeping up the best and the most promising framework ever! Hope to invest some of my efforts into its development when I gain enough experience and knowledge! Please take a closer look into the desktop support, features and modern widgets!

I’ve got a question: will the final release be packaged in a 4.9 fashion? I mean: I found quite smart, while working with the 4.8 release, to download and install different packages for the Qt library itself (and I really appreciate the option to immediatly run the precompiled demo) and for Qt Creator. I’ve seen there’s no compiled demo and there’s Qt Creator in the 5.0 RC package, so I wonder if it will stay this way.

I’ve wondered for some time why QAbstractSocket and QLocalSocket don’t have a common super class (apart from QIODevice). They have some methods in common and in MeVisLab we really have some code that needs to support both. The code would be cleaner in some places if we didn’t have to distinguish between the two. Of course, at other places it wouldn’t help, so it’s no big thing, just wondering.

I was wondering the same thing. I posted this question in the development mailinglist a few weeks ago, but from what I gathered, this wasn’t deemed important enough to add this soon before 5.0 release. It is a shame, as I have a similar use case as yours, where the client code would clean up and benefit from a common abstract socket class of some sort.

Please consider changing the documentation links for classes. The new scheme includes the module name the class belongs to which makes it very difficult to provide online links (e.g. automated by web software) to Qt classes without hardcoding mappings between classes and their modules. While this might not be top priority for developers, it will break a lot of online material that links to Qt Reference Manual. I understand the current scheme tries to keep the namespaces clean but this happens at a great cost for all online Qt communities.

Feels like scratching right ear with a left hand. It’s a lot of additional work for the engine and requires updating with every Qt version update. However it’s a step forward if I don’t find an alternative solution.

Currently what I saw – for all classes (adapters) which shall be exported from qt5webkit.dll for qt5webkitwidgets.dll __attribute__(dllexport) was setup properly, thus I have no clue – what produces the problem

All examples files in Windows version are empty…
Using Windows 7 x64, MSVC 2010.
When compiling default Gui Application, there are errors:
MAKEFILE_GENERATOR variable not set as a result of parsing : untitled2.pro. Possibly qmake was not able to find files included using "include(..)" - enable qmake debugging to investigate more.
22:10:14: The process "C:\Qt\Qt5.0.0-rc1\5.0.0-rc1\msvc2010\bin\qmake.exe" exited with code 3.
Error while building/deploying project untitled2 (kit: Desktop Qt 5.0.0-rc1 MSVC2010 32bit (SDK))
When executing step 'qmake'

“C:\Qt\Qt5.0.0-rc1\5.0.0-rc1\msvc2010\bin\qmake.exe”
I used qmake from this release. I tryed QtCreators from this distributive and 2.5.2 version. Beta versions of Qt5 were fine, but this rc1 doesn’t build applications…