From d796c9dd933ab96ec83b9a634feedd5d32e1ba3f Mon Sep 17 00:00:00 2001 From: Timothy Pearson Date: Tue, 8 Nov 2011 12:31:36 -0600 Subject: Test conversion to TQt3 from Qt3 8c6fc1f8e35fd264dd01c582ca5e7549b32ab731 --- doc/html/porting2.html | 965 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 965 insertions(+) create mode 100644 doc/html/porting2.html (limited to 'doc/html/porting2.html') diff --git a/doc/html/porting2.html b/doc/html/porting2.html new file mode 100644 index 000000000..9f44766e3 --- /dev/null +++ b/doc/html/porting2.html @@ -0,0 +1,965 @@ + + + + + +Porting to TQt 2.x + + + + + + + +
+ +Home + | +All Classes + | +Main Classes + | +Annotated + | +Grouped Classes + | +Functions +

Porting to TQt 2.x

+ + + +

+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! +

+

+

The Porting Notes

+

+

+

Namespace

+

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. +

No Default 0 Parent Widget

+

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. +

Virtual Functions

+

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. +

+

+

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). +

Collection classes

+

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). +

Debug vs. Release

+

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

+

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: +

+

+Points to note about the new TQString are: +

+
Unicode
+
+TQt 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 TQt 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 TQString is that it automatically expands +when you write to an indexed position. +

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

Use TQString
+
+Try to always use TQString. If you must, use TQCString which is the +old implementation from TQt 1.x. +

Unicode vs. ASCII
+
+Every conversion to and from ASCII is wasted time, so try to use TQString +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 TQString. +

TQString is simpler
+
+Expect your code to become simpler with the new TQString, 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) ) +

TQString(const char*, int) is removed
+
+The TQString 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 TQString::left(int) or TQString::fromLatin1( const char*, +int ) -- in both cases the int parameter signifies the number of characters. +

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

+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. +

Signals and Slots
+
+Many signal/slots have changed from const char* to TQString. You will +get run-time errors when you try to 
 TQObject::connect()
+ +to the old +signals and slots, usually with a message indicating the const TQString& +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. +

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

TQString::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 = TQString::null. +Code calling resize(n) prior to using +operator[] up to n just remove +the resize(n) completely. +

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

TQString::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 TQString as an array of bytes, in which case use +TQByteArray or TQCString instead. +

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

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

System functions
+
+You may find yourself needing latin1() for passing to the operating system +or other libraries, and be tempted to use TQCString 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 TQt 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 TQString in order to make your +application fully Unicode-aware, use TQString::null for the null value +where you would have used 0 with char pointers. +

TQString is not null terminated
+
+This means that inserting a 0-character +in the middle of the string does not change the length(). ie. +
+   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()
+ . +

TQString 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 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. +

+

TQApplication

+

In the function 

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

TQColor

+

+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. +

TQRgb

+

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. +

TQDataStream

+

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: +

+

TQWidget

+

TQWidget::recreate()

+

+This function is now called reparent(). +

TQWidget::setAcceptFocus(bool)

+

+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. +

TQWidget::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 +TQPainter::setClipRegion() superfluous. Apart from the improved +consistency, the change is likely to reduce flicker and to make TQt +event slightly faster. +

TQIODevice

+

+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)index
+ +that need to be changed. +

TQLabel

+

 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. +

TQDialog

+

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. +

TQStrList

+

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(). +

TQLayout

+

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. +

TQListView

+

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. +

TQMultiLineEdit

+

+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

+

+

 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

+

+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). +

TQScrollView

+

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. +

TQTextStream

+

+

 operator<<(TQTextStream&, TQChar&)
+ does not skip whitespace. +
 operator<<(TQTextStream&, char&)
+ does, +as was the case with TQt 1.x. This is for backward compatibility. +

TQUriDrag

+

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(). +

TQPainter

+

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::. +

TQPicture

+

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. +

TQPoint, TQPointArray, TQSize and TQRect

+

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

+

TQImage uses TQRgb for the colors - see the changes to that. +

TQPixmap

+

 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. +

TQMenuData / TQPopupMenu

+

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 (TQLineEdit, TQComboBox, TQSpinBox)

+

 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. +

TQFile, TQFileInfo, TQDir

+

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. +

TQFontMetrics

+

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

TQWindow

+

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". +

TQEvent

+

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 the removed functions

+

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 +TrolltechTrademarks +
TQt 3.3.8
+
+ -- cgit v1.2.1