HomeHome

Porting to Qt 2.x


You're probably looking at this page because you want to port your application from Qt 1.x to Qt 2.x, but to be sure, let's review the good reasons to do this:

The Qt 2.x series is not binary compatible with the 1.x series. This means programs compiled for Qt 1.x must be recompiled to work with Qt 2.x. Qt 2.x is also not completely source compatible with 1.x, however all points of incompatibility cause compiler errors (rather than mysterious results), or produce run-time messages. The result is that Qt 2.x includes many additional features, discards obsolete functionality that is easily converted to use the new features, and that porting an application from Qt 1.x to Qt 2.x is a simple task well worth the amount of effort required.

To port code using Qt 1.x to use Qt 2.x:

Many very major projects, such as KDE have been port, so there is plenty of expertise in the collective conscious that is the Qt Developer Community!

The Porting Notes

Namespace

Qt 2.x is namespace-clean, unlike 1.x. Qt now uses very few global identifiers. Identifiers like red, blue, LeftButton, AlignRight, Key_Up, Key_Down, NoBrush etc. are now part of a special class Qt (defined in qnamespace.h), which is inherited by most Qt classes. Member functions of classes that inherit from QWidget, etc. are totally unaffected, but code that is not in functions of classes inherited from Qt, you must qualify these identifiers like this: Qt::red, Qt::LeftButton, Qt::AlignRight, etc.

The qt/bin/qt20fix script helps to fix the code that needs adaption, though most code does not need changing.

Compiling with -DQT1COMPATIBILITY will help you get going with Qt 2.x - it allows all the old "dirty namespace" identifiers from Qt 1.x to continue working. Without it, you'll get compile errors that can easily be fixed by searching this page for the clean identifiers.

No Default 0 Parent Widget

In Qt 1.x, all widget constructors were defined with a default value of 0 for the parent widget. However, only the main window of the application should be created with a 0 parent, all other widgets should have parents. Having the 0 default made it too simple to create bugs by forgetting to specify the parent of non-mainwindow widgets. Such widgets would typically never be deleted (causing memory leaks), and they would become top-level widgets, confusing the window managers. Therefore, in Qt 2.x the 0 default parent has been removed for the widget classes that are not likely to be used as main windows.

Note also that programs no longer need (or should) use 0 parent just to indicate that a widget should be top-level. See 

 QWidget::isTopLevel()
for details. See also the notes about QPopupMenu and QDialog below.

Virtual Functions

Some virtual functions have changed signature in Qt 2.x. If you override them in derived classes, you must change the signature of your functions accordingly.

This is one class of changes that are not detected by the compiler, so you should mechanically search for each of these function names in your header files, eg. 

egrep -w 'setStyle|addColumn|setColumnText|setText...' *.h

Of course, you'll get a few false positives (eg. if you have a setText function that is not in a subclass of QListViewItem).

Collection classes

The collection classes include generic classes such as QGDict, QGList, and the subclasses such as QDict and QList.

The macro-based Qt collection classes are obsolete; use the template-based classes instead. Simply remove includes of qgeneric.h and replace e.g. Q_DECLARE(QCache,QPixmap) with QCache.

The GCI global typedef is replaced by QCollection::Item. Only if you make your own subclasses of the undocumented generic collection classes will you have GCI in your code. This change has been made to avoid collisions with other namespaces.

The GCF global typedef is removed (it was not used in Qt).

Debug vs. Release

The ASSERT macro is now a null expression if the CHECK_STATE flag is not set (i.e. if the NO_CHECK flag is defined).

The debug() function now outputs nothing if Qt was compiled with the NO_DEBUG macro defined.

QString

QString has undergone major changes internally, and although it is highly backward compatible, it is worth studying in detail when porting to Qt 2.x. The Qt 1.x QString class has been renamed to QCString in Qt 2.x, though if you use that you will incur a performance penalty since all Qt functions that took const char* now take const QString&.

To take full advantage of the new Internationalization functionality in Qt 2.x, the following steps are required:

Points to note about the new QString are:

Unicode
Qt now uses Unicode throughout. data() now returns a const reference to an ASCII version of the string - you cannot directly access the string as an array of bytes, because it isn't one. Often, latin1() is what you want rather than data(), or just leave it to convert to const char* automatically. data() is only used now to aide porting to Qt 2.x, and ideally you'll only need latin1() or implicit conversion when interfacing to facilities that do not have Unicode support.

Automatic-expanding
A big advantage of the new QString is that it automatically expands when you write to an indexed position.

QChar and QCharRef
QChar are the Unicode characters that make up a QString. A QCharRef is a temporary reference to a QChar in a QString that when assigned to ensures that the implicit sharing semantics of the QString are maintained. You are unlikely to use QCharRef in your own code - but so that you understand compiler error messages, just know that mystring[123] is a QCharRef whenever mystring is not a constant string. A QCharRef has basically the same functionality as a QChar, except it is more restricted in what you can assign to it and cast it to (to avoid programming errors).

Use QString
Try to always use QString. If you must, use QCString which is the old implementation from Qt 1.x.

Unicode vs. ASCII
Every conversion to and from ASCII is wasted time, so try to use QString as much as possible rather than const char*. This also ensures you have full 16-bit support.

Convertion to ASCII
The return value from operator const char*() is transient - don't expect it to remain valid while you make deep function calls. It is valid for as long as you don't modify or destroy the QString.

QString is simpler
Expect your code to become simpler with the new QString, especially places where you have used a char* to wander over the string rather than using indexes into the string.

Some hacks don't work
This hack: use_sub_string( &my_string[index] ) should be replaced by: use_sub_string( my_string.mid(index) )

QString(const char*, int) is removed
The QString constructor taking a const char* and an integer is removed. Use of this constructor was error-prone, since the length included the '\0' terminator. Use QString::left(int) or QString::fromLatin1( const char*, int ) -- in both cases the int parameter signifies the number of characters.

QString(int) is private
The QString constructor taking an integer is now private. This function is not meaningful anymore, since QString does all space allocation automatically. 99% of cases can simple be changed to use the default constructor, QString().

In Qt 1.x the constructor was used in two ways: accidentally, by attempting to convert a char to a QString (the char converts to int!) - giving strange bugs, and as a way to make a QString big enough prior to calling 

 QString::sprintf()
. In Qt 2.x, the accidental bug case is prevented (you will get a compilation error) and QString::sprintf has been made safe - you no longer need to pre-allocate space (though for other reasons, sprintf is still a poor choice - eg. it doesn't pass Unicode). The only remaining common case is conversion of 0 (NULL) to QString, which would usually give expected results in Qt 1.x. For Qt 2.x the correct syntax is to use QString::null, though note that the default constructor, QString(), creates a null string too. Assignment of 0 to a QString is ambiguous - assign QString::null; you'll mainly find these in code that has been converted from const char* types to QString. This also prevents a common error case from Qt 1.x - in that version, mystr = 'X' would not produce the expected results and was always a programming error; in Qt 2.x, it works - making a single-character string.

Also see QStrList.

Signals and Slots
Many signal/slots have changed from const char* to QString. You will get run-time errors when you try to 
 QObject::connect()

to the old signals and slots, usually with a message indicating the const QString& replacement signal/slot.

Optimize with Q2HELPER
In qt/src/tools/qstring.cpp there is a Q2HELPER - define it for some extra debugging/optimizing features (don't leave it it - it kills performance). You'll get an extra function, qt_qstring_stats(), which will print a summary of how much your application is doing Unicode and ASCII back-and-forth conversions.

QString::detach() is obsolete and removed
Since QString is now always shared, this function does nothing. Remove calls to QString::detach().

QString::resize(int size) is obsolete and removed
Code using this to truncate a string should use truncate(size-1). Code using qstr.resize(0) should use qstr = QString::null. Code calling resize(n) prior to using operator[] up to n just remove the resize(n) completely.

QString::size() is obsolete and removed
Calls to this function must be replaced by length()+1.

QString::setStr(const char*) is removed
Try to understand why you were using this. If you just meant assignment, use that. Otherwise, you are probably using QString as an array of bytes, in which case use QByteArray or QCString instead.

QString is not an array of bytes
Code that uses QString as an array of bytes should use QByteArray or a char[], then convert that to a QString if needed.

"string = 0"
Assigning 0 to a QString should be assigning the null string, ie. string = QString::null.

System functions
You may find yourself needing latin1() for passing to the operating system or other libraries, and be tempted to use QCString to save the conversion, but you are better off using Unicode throughout, then when the operating system supports Unicode, you'll be prepared. Some Unix operating systems are now beginning to have basic Unicode support, and Qt will be tracking these improvements as they become more widespread.

Bugs removed
toShort() returns 0 (and sets *ok to false) on error. toUInt() now works for big valid unsigned integers. insert() now works into the same string.

NULL pointers
When converting "const char*" usage to QString in order to make your application fully Unicode-aware, use QString::null for the null value where you would have used 0 with char pointers.

QString is not null terminated
This means that inserting a 0-character in the middle of the string does not change the length(). ie. 
   QString s = "fred";
   s[1] = '\0';
     // s.length() == 4
     // s == "f\0ed"
     // s.latin1() == "f"
   s[1] = 'r';
     // s == "fred"
     // s.latin1() == "fred"

Especially look out for this type of code: 

   QString s(2);
   s[0] = '?';
   s[1] = 0;

This creates a string 2 characters long. To find these problems while converting, you might like to add ASSERT(strlen(d->ascii)==d->len) inside 

 QString::latin1()
.

QString or Standard C++ string?

The Standard C++ Library string is not Unicode. Nor is wstring defined to be so (for the small number of platforms where it is defined at all). This is the same mistake made over and over in the history of C - only when non-8-bit characters are the norm do programmers find them usable. Though it is possible to convert between string and QString, it is less efficient than using QString throughout. For example, when using: 

    QLabel::setText( const QString& )

if you use string, like this: 

    void myclass::dostuffwithtext( const string& str )
    {
        mylabel.setText( QString(str.c_str()) );
    }

that will create a (ASCII only) copy of str, stored in mylabel. But this: 

    void myclass::dostuffwithtext( const QString& str )
    {
        mylabel.setText( str );
    }

will make an implicitly shared reference to str in the QLabel - no copying at all. This function might be 10 nested function calls away from something like this: 

    void toplevelclass::initializationstuff()
    {
        doStuff( tr("Okay") );
    }

At this point, in Qt 2.x, the tr() does a very fast dictionary lookup through memory-mapped message files, returning some Unicode QString for the appropriate language (the default being to just make a QString out of the text, of course - you're not forced to use any of these features), and that same memory mapped Unicode will be passed though the system. All occurrences of the translation of "Okay" can potentially be shared.

QApplication

In the function 

 QApplication::setColorSpec()
, PrivateColor and TrueColor are obsolete. Use ManyColor instead.

QColor

All colors (color0, color1, black, white, darkGray, gray, lightGray, red, green, blue, cyan, magenta, yellow, darkRed, darkGreen, darkBlue, darkCyan, darkMagenta, and darkYellow) are in the Qt namespace. In members of classes that inherit the Qt namespace-class (eg. QWidget subclasses), you can use the unqualified names as before, but in global functions (eg. main()), you need to qualify them: Qt::red, Qt::white, etc. See also the QRgb section below.

QRgb

In QRgb (a typedef of long), the order of the RGB channels has changed to be in the more efficient order (for typical contemporary hardware). If your code made assumptions about the order, you will get blue where you expect red and vice versa (you'll not notice the problem if you use shades of grey, green, or magenta). You should port your code to use the creator function qRgb(int r,int g,int b) and the access functions qRed(QRgb), qBlue(QRgb), and qGreen(QRgb). If you are using the alpha channel, it hasn't moved, but you should use the functions qRgba(int,int,int,int) and qAlpha(QRgb). Note also that QColor::pixel() does not return a QRgb (it never did on all platforms, but your code may have assumed so on your platform) - this may also produce strange color results - use QColor::rgb() if you want a QRgb.

QDataStream

The QDatastream serialization format of most Qt classes is changed in Qt 2.x. Use 

 QDataStream::setVersion( 1 )
to get a datastream object that can read and write Qt 1.x format data streams.

If you want to write Qt 1.x format datastreams, note the following compatibility issues:

QWidget

QWidget::recreate()

This function is now called reparent().

QWidget::setAcceptFocus(bool)

This function is removed. Calls like QWidget::setAcceptFocus(TRUE) should be replaced by 

 QWidget::setFocusPolicy(StrongFocus)
, and calls like QWidget::setAcceptFocus(FALSE) should be replaced by 
 QWidget::setFocusPolicy(NoFocus)
. Additional policies are TabFocus and ClickFocus.

QWidget::paintEvent()

paintEvent(0) is not permitted - subclasses need not check for a null event, and might crash. Never pass 0 as the argument to paintEvent(). You probably just want repaint() or update() instead.

When processing a paintEvent, painting is only permitted within the update region specified in the event. Any painting outside will be clipped away. This shouldn't break any code (it was always like this on MS-Windows) but makes many explicit calls to QPainter::setClipRegion() superfluous. Apart from the improved consistency, the change is likely to reduce flicker and to make Qt event slightly faster.

QIODevice

The protected member QIODevice::index is renamed to QIODevice::ioIndex to avoid warnings and to allow compilation with bad C libraries that check every occurrence of the string "index" in the implementation, since a compiler will not always catch cases like 

(uint)index

that need to be changed.

QLabel

 QLabel::setMargin()

 QLabel::setMargin()
and
 QLabel::margin()

have been renamed to 

 QLabel::setIndent()
and 
 QLabel::indent()
, respectively. This was done to avoid collision with QFrame::setMargin(), which is now virtual. 

 QLabel::setMovie()

Previously, setting a movie on a label cleared the value of text(). Now it doesn't. If you somehow used QLabel::text() to detect if a movie was set, you might have trouble. This is unlikely.

QDialog

The semantics of the parent pointer changed for non-modal dialogs: In Qt-2.x, dialogs are always toplevel windows. The parent, however, takes the ownership of the dialog, i.e. it will delete the dialog at destruction if it has not been explicitly deleted already. Furthermore, the window system will be able to tell that both the dialog and the parent belong together. Some X11 window managers will for instance provide a common taskbar entry in that case.

If the dialog belongs to a toplevel main window of your application, pass this main window as parent to the dialog's constructor. Old code (with 0 pointer) will still run. Old code that included QDialogs as child widgets will no longer work (it never really did). If you think you might be doing this, put a breakpoint in QDialog::QDialog() conditional on parent not being 0.

QStrList

Many methods that took a QStrList can now instead take a QStringList, which is a real list of QString values.

To use QStringList rather than QStrList, change loops that look like this: 

    QStrList list = ...;
    const char* s;
    for ( s = list.first(); s; s = list.next() ) {
        process(s);
    }

to be like this: 

    QStringList list = ...;
    QStringList::ConstIterator i;
    for ( i = list.begin(); i != list.end(); ++i ) {
        process(*i);
    }

In general, the QStrList functions are less efficient, building a temporary QStringList.

The following functions now use QStringList rather than QStrList for return types/parameters.

The following functions are added:

The rarely used static function void QFont::listSubstitutions(QStrList*) is replaced by QStringList QFont::substitutions().

QLayout

Calling resize(0,0) or resize(1,1) will no longer work magically. Remove all such calls. The default size of toplevel widgets will be their sizeHint().

The default implementation of QWidget::sizeHint() will no longer return just an invalid size; if the widget has a layout, it will return the layout's preferred size.

The special maximum MaximumHeight/Width is now QWIDGETSIZE_MAX, not QCOORD_MAX.

QBoxLayout::addWidget() now interprets the alignment parameter more aggressively. A non-default alignment now indicates that the widget should not grow to fill the available space, but should be sized according to sizeHint(). If a widget is too small, set the alignment to 0. (Zero indicates no alignment, and is the default.)

The class QGManager is removed. Subclasses of QLayout need to be rewritten to use the new, much simpler QLayout API.

For typical layouts, all use of setMinimumSize() and setFixedSize() can be removed. activate() is no longer necessary.

You might like to look at the QGrid, QVBox, and QHBox widgets - they offer a simple way to build nested widget structures.

QListView

In Qt 1.x mouse events to the viewport where redirected to the event handlers for the listview; in Qt 2.x, this functionality is in QScrollView where mouse (and other position-oriented) events are redirected to viewportMousePressEvent() etc, which in turn translate the event to the coordinate system of the contents and call contentsMousePressEvent() etc, thus providing events in the most convenient coordinate system. If you overrode QListView::MouseButtonPress(), QListView::mouseDoubleClickEvent(), QListView::mouseMoveEvent(), or QListView::mouseReleaseEvent() you must instead override viewportMousePressEvent(), viewportMouseDoubleClickEvent(), viewportMouseMoveEvent(), or viewportMouseReleaseEvent() respectively. New code will usually override contentsMousePressEvent() etc.

The signal QListView::selectionChanged(QListViewItem *) can now be emitted with a null pointer as parameter. Programs that use the argument without checking for 0, may crash.

QMultiLineEdit

The protected function 

 QMultiLineEdit::textWidth(QString*)

changed to 

 QMultiLineEdit::textWidth(const QString&)
. This is unlikely to be a problem, and you'll get a compile error if you called it.

QClipboard

 QClipboard::pixmap()
now returns a QPixmap, not a QPixmap*. The pixmap will be null if no pixmap is on the clipboard. QClipboard now offers powerful MIME-based types on the clipboard, just like drag-and-drop (in fact, you can reuse most of your drag-and-drop code with clipboard operations).

QDropSite

QDropSite is obsolete. If you simply passed this, just remove the inheritance of QDropSite and call setAcceptDrops(TRUE) in the class constructor. If you passed something other than this, your code will not work. A common case is passing the viewport() of a QListView, in which case, override the viewportDragMoveEvent(), etc. functions rather than QListView's dragMoveEvent() etc. For other cases, you will need to use an event filter to act on the drag/drop events of another widget (as is the usual way to intercept foreign events).

QScrollView

The parameters in the signal contentsMoving(int,int) are now positive rather than negative values, coinciding with setContentsPos(). Search for connections you make to this signal, and either change the slot they are connected to such that it also expects positive rather than negative values, or introduce an intermediate slot and signal that negates them.

If you used drag and drop with QScrollView, you may experience the problem described for QDropSite.

QTextStream

 operator<<(QTextStream&, QChar&)
does not skip whitespace. 
 operator<<(QTextStream&, char&)
does, as was the case with Qt 1.x. This is for backward compatibility.

QUriDrag

The class QUrlDrag is renamed to QUriDrag, and the API has been broadened to include additional conversion routines, including conversions to Unicode filenames (see the class documentation for details). Note that in Qt 1.x the QUrlDrag class used the non-standard MIME type "url/url", while QUriDrag uses the standardized "text/uri-list" type. Other identifiers affected by the Url to Uri change are QUrlDrag::setUrls() and QUrlDrag::urlToLocalFile().

QPainter

The GrayText painter flag has been removed. Use setPen( palette().disabled().foreground() ) instead.

The RasterOp enum (CopyROP, OrROP, XorROP, NotAndROP, EraseROP, NotCopyROP, NotOrROP, NotXorROP, AndROP, NotEraseROP, NotROP, ClearROP, SetROP, NopROP, AndNotROP, OrNotROP, NandROP, NorROP, LastROP) is now part of the Qt namespace class, so if you use it outside a member function, you'll need to prefix with Qt::.

QPicture

The binary storage format of QPicture is changed, but the Qt 2.x QPicture class can both read and write Qt 1.x format QPictures. No special handling is required for reading; QPicture will automatically detect the version number. In order to write a Qt 1.x format QPicture, set the formatVersion parameter to 1 in the QPicture constructor.

For writing Qt 1.x format QPictures, the compatibility issues of QDataStream applies.

It is safe to try to read a QPicture file generated with Qt 2.x (without formatVersion set to 1) with a program compiled with Qt 1.x. The program will not crash, it will just issue the warning "QPicture::play: Incompatible version 2.x" and refuse to load the picture.

QPoint, QPointArray, QSize and QRect

The basic coordinate datatype in these classes, QCOORD, is now 32 bit (int) instead of a 16 bit (short). The const values QCOORD_MIN and QCOORD_MAX have changed accordingly.

QPointArray is now actually, not only seemingly, a QArray of QPoint objects. The semi-internal workaround classes QPointData and QPointVal are removed since they are no longer needed; QPoint is used directly instead. The function 

 QPointArray::shortPoints()

provides the point array converted to short (16bit) coordinates for use with external functions that demand that format.

QImage

QImage uses QRgb for the colors - see the changes to that.

QPixmap

 QPixmap::convertToImage()
with bitmaps now guarantees that color0 pixels become color(0) in the resulting QImage. If you worked around the lack of this, you may be able to simplify your code. If you made assumptions about the previous undefined behavior, the symptom will be inverted bitmaps (eg. "inside-out" masks). 

 QPixmap::optimize(TRUE)

is replaced by 

 QPixmap::setOptimization(QPixmap::NormalOptim)

or 

 QPixmap::setOptimization(QPixmap::BestOptim)

- see the documentation to choose which is best for your application. NormalOptim is most like the Qt 1.x "TRUE" optimization.

QMenuData / QPopupMenu

In Qt 1.x, new menu items were assigned either an application-wide unique identifier or an identifier equal to the index of the item, depending on the insertItem(...) function used. In Qt 2.x this confusing situation has been cleaned up: generated identifiers are always unique across the entire application.

If your code depends on generated ids being equal to the item's index, a quick fix is to use 

 QMenuData::indexOf(int id)

in the handling function instead. You may alternatively pass 

 QMenuData::count()

as identifier when you insert the items.

Furthermore, QPopupMenus can (and should!) be created with a parent widget now, for example the main window that is used to display the popup. This way, the popup will automatically be destroyed together with its main window. Otherwise you'll have to take care of the ownership manually.

QPopupMenus are also reusable in 2.x. They may occur in different locations within one menu structure or be used as both a menubar drop-down and as a context popup-menu. This should make it possible to significantly simplify many applications.

Last but not least, QPopupMenu no longer inherits QTableView. Instead, it directly inherits QFrame.

QValidator (QLineEdit, QComboBox, QSpinBox) 

 QValidator::validate(...)

and 

 QValidator::fixup( QString & )

are now const functions. If your subclass reimplements validate() as a non-const function, you will get a compile error (validate was pure virtual).

In QLineEdit, QComboBox, and QSpinBox, setValidator(...) now takes a const pointer to a QValidator, and validator() returns a const pointer. This change highlights the fact that the widgets do not take the ownership of the validator (a validator is a QObject on its own, with its own parent - you can easily set the same validator object on many different widgets), so changing the state of such an object or deleting it is very likely a bug.

QFile, QFileInfo, QDir

File and directory names are now always Unicode strings (ie. QString). If you used QString in the past for the simplicity it offers, you'll probably have little consequence. However, if you pass filenames to system functions rather than using Qt functions (eg. if you use the Unix unlink() function rather than QFile::remove(), your code will probably only work for Latin1 locales (eg. Western Europe, the U.S.). To ensure your code will support filenames in other locales, either use the Qt functions, or convert the filenames via 

 QFile::encodeFilename()
and 
 QFile::decodeFilename()
- but do it just as you call the system function - code that mixes encoded and unencoded filenames is very error prone. See the comments in QString, such as regarding QT_NO_ASCII_CAST that can help find potential problems.

QFontMetrics

boundingRect(char) is replaced by boundingRect(QChar), but since char auto-converts to QChar, you're not likely to run into problems with this.

QWindow

This class (which was just QWidget under a different name) has been removed. If you used it, do a global search-and-replace of the word "QWindow" with "QWidget".

QEvent

The global #define macros in qevent.h have been replaced by an enum in QEvent. Use e.g. QEvent::Paint instead of Event_Paint. Same for all of: Event_None, Event_Timer, Event_MouseButtonPress, Event_MouseButtonRelease, Event_MouseButtonDblClick, Event_MouseMove, Event_KeyPress, Event_KeyRelease, Event_FocusIn, Event_FocusOut, Event_Enter, Event_Leave, Event_Paint, Event_Move, Event_Resize, Event_Create, Event_Destroy, Event_Show, Event_Hide, Event_Close, Event_Quit, Event_Accel, Event_Clipboard, Event_SockAct, Event_DragEnter, Event_DragMove, Event_DragLeave, Event_Drop, Event_DragResponse, Event_ChildInserted, Event_ChildRemoved, Event_LayoutHint, Event_ActivateControl, Event_DeactivateControl, and Event_User.

The Q_*_EVENT macros in qevent.h have been deleted. Use an explicit cast instead. The macros were: Q_TIMER_EVENT, Q_MOUSE_EVENT, Q_KEY_EVENT, Q_FOCUS_EVENT, Q_PAINT_EVENT, Q_MOVE_EVENT, Q_RESIZE_EVENT, Q_CLOSE_EVENT, Q_SHOW_EVENT, Q_HIDE_EVENT, and Q_CUSTOM_EVENT.

QChildEvents are now sent for all QObjects, not just QWidgets. You may need to add extra checking if you use a QChildEvent without much testing of its values.

All the removed functions

All these functions have been removed in Qt 2.x. Most are simply cases where "const char*" has changed to "const QString&", or when an enumeration type has moved into the Qt:: namespace (which, technically, is a new name, but your code will compile just the same anyway). This list is provided for completeness.

Copyright © 2000 TrolltechTrademarks
Qt version 2.2.1