![]() |
Home · Overviews · Examples |
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.
In Qt 4.3:
QtCore | Core non-GUI functionality |
QtGui | Core GUI functionality |
QtNetwork | Network module |
QtOpenGL | OpenGL module |
QtSql | SQL module |
QtSvg | SVG rendering classes |
QtXml | XML module |
Qt3Support | Qt 3 support classes |
QAxContainer | ActiveQt client extension |
QAxServer | ActiveQt server extension |
QtAssistant | Classes for launching Qt Assistant |
QtDesigner | Classes for extending and embedding Qt Designer |
QtUiTools | Classes for dynamic GUI generation |
QtTest | Tool classes for unit testing |
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 -= guito your .pro file. To enable the other libraries, add the line
QT += network opengl sql qt3supportAnother 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 <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>
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:
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".
MyWidget::MyWidget(QWidget *parent, const char *name) : QWidget(parent, name) { ... }
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:
// DEPRECATED 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) { ... }
Example:
QLabel *label = new QLabel; QPointer<QLabel> safeLabel = label; safeLabel->setText("Hello world!"); delete label; // safeLabel is now 0, whereas label is a dangling pointerQPointer<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.
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.
QT += qt3supportto 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
DEFINES += QT3_SUPPORTto your .pro file.
If you want to use compatibility functions but don't want to link against the Qt3Support library, add the line
DEFINES += QT3_SUPPORT_WARNINGSor
DEFINES += QT3_SUPPORTto your .pro file, depending on whether you want compatibility function calls to generate compiler warnings or not.
Copyright © 2008 Trolltech | Trademarks | Qt Jambi 4.4.0_01 |