Viadeo Twitter Google Bookmarks ! Facebook Digg MySpace Yahoo MyWeb Blinklist Netvouz Reddit Simpy StumbleUpon Bookmarks Windows Live Favorites 
Logo Documentation Qt ·  Page d'accueil  ·  Toutes les classes  ·  Toutes les fonctions  ·  Vues d'ensemble  · 

What's New in Qt 4

This document covers the most important differences between Qt 3 and Qt 4. Although it is not intended to be a comprehensive porting guide, it tells you about the most important portability issues that you may encounter. It also explains how to turn on Qt 3 compatibility support.

New Technologies in Qt 4

Qt 4 introduces the following core technologies:

  • Tulip, a new set of template container classes.
  • Interview, a model/view architecture for item views.
  • Arthur, the Qt 4 painting framework.
  • Scribe, the Unicode text renderer with a public API for performing low-level text layout.
  • Mainwindow, a modern action-based mainwindow, toolbar, menu, and docking architecture.
  • The new Qt Designer user interface design tool.

Recent Additions to Qt 4

The following features have been added to Qt since the first release of Qt 4:

In Qt 4.5:

  • The WebKit browser engine included with Qt has been upgraded to the latest upstream (trunk) version of WebKit, bringing the latest features and improvements to Qt applications.
  • Qt for Mac OS X has been substantially rewritten to use Apple's Cocoa API, enabling Qt applications to be deployed on 64-bit Macintosh hardware.
  • The QtXmlPatterns module has been extended to cover XSLT, a transformation language for XML documents.
  • Qt Script introduced its debugger, providing error reporting for scripts, and to let users track down bugs in their own scripts.
  • Qt 4.5 includes support for writing rich text documents as OpenDocument files via the newly-introduced QTextDocumentWriter class.
  • Qt Linguist can load and edit multiple translation files simultaneously.
  • Support for ARGB top-level widgets (i.e., translucent windows).

In Qt 4.4:

In Qt 4.3:

  • Support for different main window paradigms and styles, such as those found in Visual Studio or KDevelop.
  • The QtScript module, providing support for application scripting with ECMAScript.
  • Improved graphics features, including an experimental Direct3D paint engine and improved provision for hardware accelerated rendering with OpenGL, and support for OpenGL ES in Qt for Embedded Linux.
  • Scalable Vector Graphics (SVG) export, allowing SVG drawings to be created using the standard QPainter API.
  • Support for arbitrary matrix transformations and set operations on painter paths.
  • Native look and feel on Windows Vista; improved look and feel on Mac OS X.
  • An improved Multiple Document Interface (MDI) implementation.
  • Continuous improvements to Qt Designer, including support for dynamic properties.
  • Support for Secure Socket Layer (SSL) communications via the QSslSocket class.
  • Support for XML Localization Interchange File Format (XLIFF) files in Qt Linguist.
  • A new font subsystem for Qt for Embedded Linux.

In Qt 4.2:

In Qt 4.1:

For more information about improvements in each Qt release, see the detailed lists of changes.

Significant Improvements

The following modules have been significantly improved for Qt 4:

  • A fully cross-platform accessibility module, with support for the emerging SP-API Unix standard in addition to Microsoft and Mac Accessibility.
  • The SQL module, which is now based on the Interview model/view framework.
  • The network module, with better support for UDP and synchronous sockets.
  • The style API, which is now decoupled from the widgets, meaning that you can draw any user interface element on any device (widget, pixmap, etc.).
  • Enhanced thread support, with signal-slot connections across threads and per-thread event loops.
  • A new resource system for embedding images and other resource files into the application executable.

Build System

Unlike previous Qt releases, Qt 4 is a collection of smaller libraries:

QtCoreCore non-GUI functionality
QtGuiCore GUI functionality
QtNetworkNetwork module
QtOpenGLOpenGL module
QtSqlSQL module
QtSvgSVG rendering classes
QtXmlXML module
Qt3SupportQt 3 support classes
QAxContainerActiveQt client extension
QAxServerActiveQt server extension
QtAssistantClasses for launching Qt Assistant
QtDesignerClasses for extending and embedding Qt Designer
QtUiToolsClasses for dynamic GUI generation
QtTestTool classes for unit testing

QtCore contains tool classes like QString, QList, and QFile, as well as kernel classes like QObject and QTimer. The QApplication class has been refactored so that it can be used in non-GUI applications. It is split into QCoreApplication (in QtCore) and QApplication (in QtGui).

This split makes it possible to develop server applications using Qt without linking in any unnecessary GUI-related code and without requiring GUI-related system libraries to be present on the target machine (e.g. Xlib on X11, Carbon on Mac OS X).

If you use qmake to generate your makefiles, qmake will by default link your application against QtCore and QtGui. To remove the dependency upon QtGui, add the line

 QT -= gui

to your .pro file. To enable the other libraries, add the line

 QT += network opengl sql qt3support

Another change to the build system is that moc now understands preprocessor directives. qmake automatically passes the defines set for your project (using "DEFINES +=") on to moc, which has its own built-in C++ preprocessor.

To compile code that uses UI files, you will also need this line in the .pro file:

 CONFIG += uic3

Include Syntax

The syntax for including Qt class definitions has become

 #include <QClassName>

For example:

 #include <QString>
 #include <QApplication>
 #include <QSqlTableModel>

This is guaranteed to work for any public Qt class. The old syntax,

 #include <qclassname.h>

still works, but we encourage you to switch to the new syntax.

If you attempt to include a header file from a library that isn't linked against the application, this will result in a compile-time warning (e.g., "QSqlQuery: No such file or directory"). You can remedy to this problem either by removing the offending include or by specifying the missing library in the QT entry of your .pro file (see Build System above).

To include the definitions for all the classes in a library, simply specify the name of that library. For example:

 #include <QtCore>


Qt 2 introduced a class called Qt for global-like constants (e.g., Qt::yellow). The C++ namespace construct was not used because not all compilers understood it when it was released.

With Qt 4, the Qt class has become the Qt namespace. If you want to access a constant that is part of the Qt namespace, prefix it with Qt:: (e.g., Qt::yellow), or add the directive

 using namespace Qt;

at the top of your source files, after your #include directives. If you use the using namespace syntax you don't need the prefix (e.g., yellow is sufficient).

When porting Qt 3 applications, you may run into some source compatibility problems with some of these symbols. For example, in Qt 3, it was legal to write QWidget::yellow instead of Qt::yellow, because QWidget inherited from Qt. This won't work in Qt 4; you must write Qt::yellow or add the "using namespace" directive and drop the Qt:: prefix.

The qt3to4 porting tool automates this conversion.

QObject/QWidget Constructors

In Qt 4 we have tried to simplify the constructors of QObject/QWidget subclasses. This makes subclassing easier, at the same time as it helps make the Qt library more efficient.

Constructors no longer take a "const char *name" parameter. If you want to specify a name for a QObject, you must call QObject::setObjectName() after construction. The object name is now a QString. The reasons for this change are:

  • Code that used it looked confusing, for example:
     QLabel *label1 = new QLabel("Hello", this);
     QLabel *label2 = new QLabel(this, "Hello");

    label1 is a QLabel that displays the text "Hello"; label2 is a QLabel with no text, with the object name "Hello".

  • From surveys we did, most users didn't use the name, although they blindly followed Qt's convention and provided a "const char *name" in their subclasses's constructors. For example:
     MyWidget::MyWidget(QWidget *parent, const char *name)
         : QWidget(parent, name)
  • The name parameter was in Qt since version 1, and it always was documented as: "It is not very useful in the current version of Qt, but it will become increasingly important in the future." Ten years later, it still hasn't fulfilled its promise.

QWidget's WFlags data type has been split in two: Qt::WindowFlags specifies low-level window flags (the type of window and the frame style), whereas Qt::WidgetAttribute specifies various higher-level attributes about the widget (e.g., WA_StaticContents). Widget attributes can be set at any time using QWidget::setAttribute(); low-level window flags can be passed to the QWidget constructor or set later using QWidget::setParent(). As a consequence, the constructors of most QWidget subclasses don't need to provide a WFlags parameter.

The parent parameter of all QObject classes in Qt defaults to a 0 pointer, as it used to do in Qt 1. This enables a style of programming where widgets are created without parents and then inserted in a layout, at which point the layout automatically reparents them.

Dynamic Casts

Qt 4 provides a qobject_cast<>() function that performs a dynamic cast based on the meta-information generated by moc for QObject subclasses. Unlike the standard C++ dynamic_cast<>() construct, qobject_cast<>() works even when RTTI is disabled, and it works correctly across DLL boundaries.

Here's the Qt 3 idiom to cast a type to a subtype:

 if (obj->inherits("QPushButton")) {
     QPushButton *pushButton = (QPushButton *)obj;

The Qt 4 idiom is both cleaner and safer, because typos will always result in compiler errors:

 QPushButton *pushButton = qobject_cast<QPushButton *>(obj);
 if (pushButton) {


The QPointer<T> class provides a pointer to type T (where T inherits from QObject) that is automatically set to 0 when the referenced object is destroyed. Guarded pointers are useful whenever you want to store a pointer to an object you do not own.


 QLabel *label = new QLabel;
 QPointer<QLabel> safeLabel = label;
 safeLabel->setText("Hello world!");
 delete label;
 // safeLabel is now 0, whereas label is a dangling pointer

QPointer<T> is more or less the same as the old QGuardedPtr<T> class, except that it is now implemented in a much more lightweight manner than before. The cost of one QPointer<T> object is now approximately the same as that of a signal--slot connection.

Paint Events

Qt 4 supports double buffering transparently on all platforms. This feature can be turned off on a per-widget basis by calling QWidget::setAttribute(Qt::WA_PaintOnScreen).

A consequence of this is that all painting must now be done from the paintEvent() function. This is also required by the HIView API on Mac OS X. In practice, this is seldom a problem, since you can call update() from anywhere in your code to create a paint event, with the region to update as the argument.

To help porting, QWidget supports a Qt::WA_PaintOutsidePaintEvent attribute that can be set to make it possible to paint outside paintEvent() on Windows and X11.

Qt 3 Support Layer

Qt 4 provides an extension library that applications based on Qt 3, called Qt3Support, that Qt applications can link against. This allows for more compatibility than ever before, without bloating Qt.

  • Classes that have been replaced by a different class with the same name, such as QListView, and classes that no longer exist in Qt 4 are available with a 3 in their name (e.g., Q3ListView, Q3Accel).
  • Other classes provide compatibility functions. Most of these are implemented inline, so that they don't bloat the Qt libraries.

To enable the Qt 3 support classes and functions, add the line

 QT += qt3support

to your .pro file.

On Visual C++ 7 and GCC 3.2+, using compatibility functions often results in a compiler warning (e.g., "'find' is deprecated"). If you want to turn off that warning, add the line


to your .pro file.

If you want to use compatibility functions but don't want to link against the Qt3Support library, add the line




to your .pro file, depending on whether you want compatibility function calls to generate compiler warnings or not.

[Next: The Tulip Container Classes]


Best Of

Actualités les plus lues


Le blog Digia au hasard


Créer des applications avec un style Metro avec Qt, exemples en QML et C++, un article de Digia Qt traduit par Thibaut Cuvelier

Le blog Digia est l'endroit privilégié pour la communication sur l'édition commerciale de Qt, où des réponses publiques sont apportées aux questions les plus posées au support. Lire l'article.



Liens utiles


  • Vous souhaitez rejoindre la rédaction ou proposer un tutoriel, une traduction, une question... ? Postez dans le forum Contribuez ou contactez-nous par MP ou par email (voir en bas de page).

Qt dans le magazine

Cette page est une traduction d'une page de la documentation de Qt, écrite par Nokia Corporation and/or its subsidiary(-ies). Les éventuels problèmes résultant d'une mauvaise traduction ne sont pas imputables à Nokia. Qt 4.6
Copyright © 2012 Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon, vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts. Cette page est déposée à la SACD.
Vous avez déniché une erreur ? Un bug ? Une redirection cassée ? Ou tout autre problème, quel qu'il soit ? Ou bien vous désirez participer à ce projet de traduction ? N'hésitez pas à nous contacter ou par MP !

Hébergement Web