| Home | All Classes | Main Classes | Annotated | Grouped Classes | Functions | |
You're probably looking at this page because you want to port your application from TQt 1.x to TQt 2.x, but to be sure, let's review the good reasons to do this:
The TQt 2.x series is not binary compatible with the 1.x series. This means programs compiled for TQt 1.x must be recompiled to work with TQt 2.x. TQt 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 TQt 2.x includes many additional features, discards obsolete functionality that is easily converted to use the new features, and that porting an application from TQt 1.x to TQt 2.x is a simple task well worth the amount of effort retquired.
To port code using TQt 1.x to use TQt 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 TQt Developer Community!
TQt 2.x is namespace-clean, unlike 1.x. TQt 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 TQt (defined in qnamespace.h),
which is inherited by
most TQt classes. Member functions of classes that inherit from TQWidget,
etc. are totally unaffected, but code that is
not in functions of classes inherited from TQt,
you must qualify these identifiers like this: TQt::red,
TQt::LeftButton, TQt::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 TQt 2.x - it allows all the old "dirty namespace" identifiers from TQt 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.
In TQt 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 TQt 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
TQWidget::isTopLevel()for details. See also the notes about TQPopupMenu and TQDialog below.
Some virtual functions have changed signature in TQt 2.x. If you override them in derived classes, you must change the signature of your functions accordingly.
TQWidget::setStyle(GUIStyle)
TQListView::addColumn(const char *, int)
TQListView::setColumnText(int, const char *)
TQListViewItem::setText(int, const char *)
TQMultiLineEdit::insertLine(const char *, int)
TQMultiLineEdit::insertAt(const char *, int, int, bool)
TQSpinBox::setPrefix(const char *)
TQSpinBox::setSuffix(const char *)
TQToolButton::setTextLabel(const char *, bool)
TQDoubleValidator::validate(TQString &, int &)
TQIntValidator::validate(TQString &, int &)
TQValidator::fixup(TQString &)
TQSlider::paintSlider(TQPainter *, const TQRect &)
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 TQListViewItem).
The collection classes include generic classes such as TQGDict, TQGList, and the subclasses such as TQDict and TQList.
The macro-based TQt collection classes are obsolete; use the
template-based classes instead. Simply remove includes of qgeneric.h and
replace e.g. Q_DECLARE(TQCache,TQPixmap) with TQCache The GCI global typedef is replaced by TQCollection::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 TQt).
The Q_ASSERT macro is now a null expression if the QT_CHECK_STATE flag
is not set (i.e. if the QT_NO_CHECK flag is defined).
The debug() function now outputs nothing if TQt was compiled with
the QT_NO_DEBUG macro defined.
TQString has undergone major changes internally, and although it is highly
backward compatible, it is worth studying in detail when porting to TQt 2.x.
The TQt 1.x TQString class has been renamed to TQCString in TQt 2.x, though if
you use that you will incur a performance penalty since all TQt functions
that took const char* now take const TQString&.
To take full advantage of the new Internationalization
functionality in TQt 2.x, the following steps are retquired:
If you find that you are mixing usage of TQCString, TQString,
and TQByteArray, this causes lots of unnecessary copying and
might indicate that the true nature of the data you are
dealing with is uncertain. If the data is NUL-terminated
8-bit data, use TQCString; if it is unterminated (ie.
contains NULs) 8-bit data, use TQByteArray; if it is text,
use TQString.
Debug vs. Release
TQString
TQString::latin1()
to catch places where
Unicode information is being converted to ASCII (loosing
information if your user in not using Latin1). TQt has
a small number of calls to this - ignore those. As a stricter
alternative, compile your code with QT_NO_ASCII_CAST defined,
which hides the automatic conversion of TQString to const char*,
so you can catch problems at compile time.
Points to note about the new TQString are:
In TQt 1.x the constructor was used in two ways: accidentally, by attempting to convert a char to a TQString (the char converts to int!) - giving strange bugs, and as a way to make a TQString big enough prior to calling
TQString::sprintf(). In TQt 2.x, the accidental bug case is prevented (you will get a compilation error) and TQString::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 TQString, which would usually give expected results in TQt 1.x. For TQt 2.x the correct syntax is to use TQString::null, though note that the default constructor, TQString(), creates a null string too. Assignment of 0 to a TQString is ambiguous - assign TQString::null; you'll mainly find these in code that has been converted from const char* types to TQString. This also prevents a common error case from TQt 1.x - in that version, mystr = 'X' would not produce the expected results and was always a programming error; in TQt 2.x, it works - making a single-character string.
Also see TQStrList.
TQObject::connect()to the old signals and slots, usually with a message indicating the const TQString& replacement signal/slot.
TQString 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:
TQString 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 Q_ASSERT(strlen(d->ascii)==d->len) inside
TQString::latin1().
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 TQString, it is less efficient than using TQString throughout. For example, when using:
TQLabel::setText( const TQString& )
if you use string, like this:
void myclass::dostuffwithtext( const string& str )
{
mylabel.setText( TQString(str.c_str()) );
}
that will create a (ASCII only) copy of str, stored in mylabel.
But this:
void myclass::dostuffwithtext( const TQString& str )
{
mylabel.setText( str );
}
will make an implicitly shared reference to str in the TQLabel - 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 TQt 2.x, the tr() does a very fast dictionary lookup
through memory-mapped message files, returning some Unicode TQString for
the appropriate language (the default being to just make a TQString 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.
In the function
TQApplication::setColorSpec(), PrivateColor and TrueColor are obsolete. Use ManyColor instead.
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 TQt namespace. In members of classes that inherit the TQt namespace-class (eg. TQWidget subclasses), you can use the unqualified names as before, but in global functions (eg. main()), you need to qualify them: TQt::red, TQt::white, etc. See also the TQRgb section below.
In TQRgb (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 gray, 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(TQRgb), qBlue(TQRgb), and qGreen(TQRgb). If you are using the alpha channel, it hasn't moved, but you should use the functions qRgba(int,int,int,int) and qAlpha(TQRgb). Note also that TQColor::pixel() does not return a TQRgb (it never did on all platforms, but your code may have assumed so on your platform) - this may also produce strange color results - use TQColor::rgb() if you want a TQRgb.
The TQDatastream serialization format of most TQt classes is changed in TQt 2.x. Use
TQDataStream::setVersion( 1 )to get a datastream object that can read and write TQt 1.x format data streams.
If you want to write TQt 1.x format datastreams, note the following compatibility issues:
TQString::latin1().
This function is now called reparent().
This function is removed. Calls like TQWidget::setAcceptFocus(TRUE) should be replaced by
TQWidget::setFocusPolicy(StrongFocus), and calls like TQWidget::setAcceptFocus(FALSE) should be replaced by
TQWidget::setFocusPolicy(NoFocus). Additional policies are TabFocus and ClickFocus.
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 TQPainter::setClipRegion() superfluous. Apart from the improved consistency, the change is likely to reduce flicker and to make TQt event slightly faster.
The protected member TQIODevice::index is renamed to TQIODevice::ioIndex to avoid warnings and to allow compilation with bad C libraries that #define index to strchr. If you have made a subclass of TQIODevice, check every occurrence of the string "index" in the implementation, since a compiler will not always catch cases like
(uint)indexthat need to be changed.
TQLabel::setMargin()
TQLabel::setMargin()and
TQLabel::margin()have been renamed to
TQLabel::setIndent()and
TQLabel::indent(), respectively. This was done to avoid collision with TQFrame::setMargin(), which is now virtual.
TQLabel::setMovie()
Previously, setting a movie on a label cleared the value of text(). Now it doesn't. If you somehow used TQLabel::text() to detect if a movie was set, you might have trouble. This is unlikely.
The semantics of the parent pointer changed for modeless dialogs: In TQt-2.x, dialogs are always top level 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 top level 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 TQDialogs as child widgets will no longer work (it never really did). If you think you might be doing this, put a breakpoint in TQDialog::TQDialog() conditional on parent not being 0.
Many methods that took a TQStrList can now instead take a TQStringList, which is a real list of TQString values.
To use TQStringList rather than TQStrList, change loops that look like this:
TQStrList list = ...;
const char* s;
for ( s = list.first(); s; s = list.next() ) {
process(s);
}
to be like this:
TQStringList list = ...;
TQStringList::ConstIterator i;
for ( i = list.begin(); i != list.end(); ++i ) {
process(*i);
}
In general, the TQStrList functions are less efficient, building a temporary TQStringList.
The following functions now use TQStringList rather than TQStrList for return types/parameters.
The following functions are added:
The rarely used static function void TQFont::listSubstitutions(TQStrList*) is replaced by TQStringList TQFont::substitutions().
Calling resize(0,0) or resize(1,1) will no longer work magically. Remove all such calls. The default size of top level widgets will be their sizeHint().
The default implementation of TQWidget::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 TQWIDGETSIZE_MAX, not TQCOORD_MAX.
TQBoxLayout::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 TQGManager is removed. Subclasses of TQLayout need to be rewritten to use the new, much simpler TQLayout 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 TQGrid, TQVBox, and TQHBox widgets - they offer a simple way to build nested widget structures.
In TQt 1.x mouse events to the viewport where redirected to the event handlers for the listview; in TQt 2.x, this functionality is in TQScrollView 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 TQListView::MouseButtonPress(), TQListView::mouseDoubleClickEvent(), TQListView::mouseMoveEvent(), or TQListView::mouseReleaseEvent() you must instead override viewportMousePressEvent(), viewportMouseDoubleClickEvent(), viewportMouseMoveEvent(), or viewportMouseReleaseEvent() respectively. New code will usually override contentsMousePressEvent() etc.
The signal TQListView::selectionChanged(TQListViewItem *) can now be emitted with a null pointer as parameter. Programs that use the argument without checking for 0, may crash.
The protected function
TQMultiLineEdit::textWidth(TQString*)changed to
TQMultiLineEdit::textWidth(const TQString&). This is unlikely to be a problem, and you'll get a compile error if you called it.
TQClipboard::pixmap()now returns a TQPixmap, not a TQPixmap*. The pixmap will be null if no pixmap is on the clipboard. TQClipboard 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).
TQDropSite is obsolete. If you simply passed this, just remove the inheritance of TQDropSite 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 TQListView, in which case, override the contentsDragMoveEvent(), etc. functions rather than TQListView'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).
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 TQScrollView, you may experience the problem described for TQDropSite.
operator<<(TQTextStream&, TQChar&)does not skip whitespace.
operator<<(TQTextStream&, char&)does, as was the case with TQt 1.x. This is for backward compatibility.
The class TQUrlDrag is renamed to TQUriDrag, 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 TQt 1.x the TQUrlDrag class used the non-standard MIME type "url/url", while TQUriDrag uses the standardized "text/uri-list" type. Other identifiers affected by the Url to Uri change are TQUrlDrag::setUrls() and TQUrlDrag::urlToLocalFile().
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 TQt namespace class, so if you use it outside a member function, you'll need to prefix with TQt::.
The binary storage format of TQPicture is changed, but the TQt 2.x TQPicture class can both read and write TQt 1.x format TQPictures. No special handling is retquired for reading; TQPicture will automatically detect the version number. In order to write a TQt 1.x format TQPicture, set the formatVersion parameter to 1 in the TQPicture constructor.
For writing TQt 1.x format TQPictures, the compatibility issues of TQDataStream applies.
It is safe to try to read a TQPicture file generated with TQt 2.x (without formatVersion set to 1) with a program compiled with TQt 1.x. The program will not crash, it will just issue the warning "TQPicture::play: Incompatible version 2.x" and refuse to load the picture.
The basic coordinate datatype in these classes, TQCOORD, is now 32 bit (int) instead of a 16 bit (short). The const values TQCOORD_MIN and TQCOORD_MAX have changed accordingly.
TQPointArray is now actually, not only seemingly, a TQArray of TQPoint objects. The semi-internal workaround classes TQPointData and TQPointVal are removed since they are no longer needed; TQPoint is used directly instead. The function
TQPointArray::shortPoints()provides the point array converted to short (16bit) coordinates for use with external functions that demand that format.
TQImage uses TQRgb for the colors - see the changes to that.
TQPixmap::convertToImage()with bitmaps now guarantees that color0 pixels become color(0) in the resulting TQImage. 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).
TQPixmap::optimize(TRUE)is replaced by
TQPixmap::setOptimization(TQPixmap::NormalOptim)or
TQPixmap::setOptimization(TQPixmap::BestOptim)- see the documentation to choose which is best for your application. NormalOptim is most like the TQt 1.x "TRUE" optimization.
In TQt 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 TQt 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 tquick fix is to use
TQMenuData::indexOf(int id)in the handling function instead. You may alternatively pass
TQMenuData::count()as identifier when you insert the items.
Furthermore, TQPopupMenus 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.
TQPopupMenus 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, TQPopupMenu no longer inherits TQTableView. Instead, it directly inherits TQFrame.
TQValidator::validate(...)and
TQValidator::fixup( TQString & )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 TQLineEdit, TQComboBox, and TQSpinBox, setValidator(...) now takes a const pointer to a TQValidator, 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 TQObject 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.
File and directory names are now always Unicode strings (ie. TQString). If you used TQString 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 TQt functions (eg. if you use the Unix unlink() function rather than TQFile::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 TQt functions, or convert the filenames via
TQFile::encodeFilename()and
TQFile::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 TQString, such as regarding QT_NO_ASCII_CAST that can help find potential problems.
boundingRect(char) is replaced by boundingRect(TQChar), but since char auto-converts to TQChar, you're not likely to run into problems with this.
This class (which was just TQWidget under a different name) has been removed. If you used it, do a global search-and-replace of the word "TQWindow" with "TQWidget".
The global #define macros in qevent.h have been replaced by an enum in TQEvent. Use e.g. TQEvent::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.
TQChildEvents are now sent for all TQObjects, not just TQWidgets. You may need to add extra checking if you use a TQChildEvent without much testing of its values.
All these functions have been removed in TQt 2.x. Most are simply cases where "const char*" has changed to "const TQString&", or when an enumeration type has moved into the TQt:: namespace (which, technically, is a new name, but your code will compile just the same anyway). This list is provided for completeness.
| Copyright © 2007 Trolltech | Trademarks | TQt 3.3.8
|