diff options
Diffstat (limited to 'doc/porting2.doc')
| -rw-r--r-- | doc/porting2.doc | 136 |
1 files changed, 68 insertions, 68 deletions
diff --git a/doc/porting2.doc b/doc/porting2.doc index dddd972d..639a5a83 100644 --- a/doc/porting2.doc +++ b/doc/porting2.doc @@ -1,10 +1,10 @@ /**************************************************************************** ** -** Help with porting from Qt 1.x to Qt 2.x +** Help with porting from TQt 1.x to TQt 2.x ** ** Copyright (C) 1992-2008 Trolltech ASA. All rights reserved. ** -** This file is part of the Qt GUI Toolkit. +** This file is part of the TQt GUI Toolkit. ** ** This file may be used under the terms of the GNU General ** Public License versions 2.0 or 3.0 as published by the Free @@ -13,7 +13,7 @@ ** Alternatively you may (at your option) use any later version ** of the GNU General Public License if such license has been ** publicly approved by Trolltech ASA (or its successors, if any) -** and the KDE Free Qt Foundation. +** and the KDE Free TQt Foundation. ** ** Please review the following information to ensure GNU General ** Public Licensing requirements will be met: @@ -39,49 +39,49 @@ /*! \page porting2.html -\title Porting to Qt 2.x +\title Porting to TQt 2.x <p> 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 +your application from TQt 1.x to TQt 2.x, but to be sure, let's review the good reasons to do this: <ul> - <li>To get access to all the new Qt 2.x features like the rich text + <li>To get access to all the new TQt 2.x features like the rich text HTML subset for formatted labels, tooltips, online help etc. and the much easier to use layout classes and widgets. <li>To make your application truly international, with support for Unicode and translations for the languages of the world. <li>To allow your application to fit into the new look of the Unix desktop with configurable, very powerful "themes". The - extended style system also integrates Qt applications better - on MS-Windows desktops. Qt will automatically chose the right + extended style system also integrates TQt applications better + on MS-Windows desktops. TQt will automatically chose the right colors and fonts and obey global system setting changes. - <li>To stay up-to-date with the version of Qt that gets all the + <li>To stay up-to-date with the version of TQt that gets all the new features and bug-fixes. <li>To get more speed and smoother widgets display with all the new anti-flicker changes in Qt. - <li>Most of all though, you want to port to Qt 2.x + <li>Most of all though, you want to port to TQt 2.x so that your Wheel Mouse works! </ul> <p> -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 <em>source</em> compatible +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 <em>source</em> 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, +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 Qt 1.x to Qt 2.x is +features, and that porting an application from TQt 1.x to TQt 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: +To port code using TQt 1.x to use TQt 2.x: <ul> <li> Briefly read the porting notes below to get an idea of what to expect. - <li> Be sure your code compiles and runs well on all your target platforms with Qt 1.x. - <li> Recompile with Qt 2.x. For each error, search below for related + <li> Be sure your code compiles and runs well on all your target platforms with TQt 1.x. + <li> Recompile with TQt 2.x. For each error, search below for related identifiers (eg. function names, class names) - this documented is structured to mention all relevant identifiers to facilitate such searching, even if that makes it a little verbose. @@ -93,7 +93,7 @@ To port code using Qt 1.x to use Qt 2.x: Many very major projects, such as <a href="http://www.kde.org/">KDE</a> have been port, so there is plenty of expertise in the collective conscious -that is the Qt Developer Community! +that is the TQt Developer Community! </p> @@ -146,12 +146,12 @@ that is the Qt Developer Community! <h3><a name="Namespace">Namespace</a></h3> -<p> Qt 2.x is namespace-clean, unlike 1.x. Qt now uses very few +<p> TQt 2.x is namespace-clean, unlike 1.x. TQt now uses very few global identifiers. Identifiers like <code>red, blue, LeftButton, AlignRight, Key_Up, Key_Down, NoBrush</code> etc. are now part of a special class <code>Qt</code> (defined in ntqnamespace.h), which is inherited by -most Qt classes. Member functions of classes that inherit from QWidget, +most TQt classes. Member functions of classes that inherit from QWidget, etc. are totally unaffected, but code that is <em>not</em> in functions of classes inherited from <code>Qt</code>, you must qualify these identifiers like this: <code>Qt::red, @@ -160,21 +160,21 @@ Qt::LeftButton, Qt::AlignRight</code>, etc. <p>The <code>qt/bin/tqt20fix</code> 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 +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. <h3><a name="DefaultParent">No Default 0 Parent Widget</a></h3> -In Qt 1.x, all widget constructors were defined with a default value +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 Qt 2.x the 0 default parent has been removed +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 @@ -185,7 +185,7 @@ below. <h3><a name="Virtual">Virtual Functions</a></h3> -<p> Some virtual functions have changed signature in Qt 2.x. +<p> 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. @@ -225,7 +225,7 @@ function that is not in a subclass of QListViewItem). classes such as QGDict, QGList, and the subclasses such as QDict and QList. -<p> The macro-based Qt collection classes are obsolete; use the +<p> The macro-based TQt collection classes are obsolete; use the template-based classes instead. Simply remove includes of ntqgeneric.h and replace e.g. Q_DECLARE(QCache,QPixmap) with QCache<QPixmap>. @@ -243,21 +243,21 @@ This change has been made to avoid collisions with other namespaces. <p>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). -<p>The debug() function now outputs nothing if Qt was compiled with +<p>The debug() function now outputs nothing if TQt was compiled with the QT_NO_DEBUG macro defined. <h3><a name="QString">QString</a></h3> 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 +backward compatible, it is worth studying in detail when porting to TQt 2.x. +The TQt 1.x QString class has been renamed to QCString 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 QString&. <p> To take full advantage of the new Internationalization -functionality in Qt 2.x, the following steps are required: +functionality in TQt 2.x, the following steps are required: <ul> <li> Start converting all uses of "const char*" in parameters to @@ -278,14 +278,14 @@ functionality in Qt 2.x, the following steps are required: <li> Put a breakpoint in \code QString::latin1()\endcode to catch places where Unicode information is being converted to ASCII (loosing - information if your user in not using Latin1). Qt has + 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 QString to const char*, so you can catch problems at compile time. </p> - <li> See the Qt \link i18n.html Internationalization page\endlink + <li> See the TQt \link i18n.html Internationalization page\endlink for information about the full process of internationalizing your software. </ul> @@ -296,12 +296,12 @@ Points to note about the new QString are: <dl compact> <dt><b>Unicode</b></dt> <dd> - Qt now uses Unicode throughout. + TQt now uses Unicode throughout. data() now returns a <em>const</em> 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, + 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. @@ -324,7 +324,7 @@ in what you can assign to it and cast it to (to avoid programming errors). <dt><b>Use QString</b></dt> <dd> Try to always use QString. If you <em>must</em>, use QCString which is the -old implementation from Qt 1.x. +old implementation from TQt 1.x. <dt><b>Unicode vs. ASCII</b></dt> <dd> @@ -365,23 +365,23 @@ is not meaningful anymore, since QString does all space allocation automatically. 99% of cases can simple be changed to use the default constructor, QString(). <p> -In Qt 1.x the constructor was used in two ways: accidentally, +In TQt 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 \code QString::sprintf()\endcode. In Qt 2.x, the accidental bug case is +calling \code QString::sprintf()\endcode. In TQt 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 +would usually give expected results in TQt 1.x. For TQt 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 +This also prevents a common error case from TQt 1.x - in that version, mystr = 'X' would <em>not</em> produce the expected -results and was always a programming error; in Qt 2.x, it works - making +results and was always a programming error; in TQt 2.x, it works - making a single-character string. <p> @@ -444,7 +444,7 @@ 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 + are now beginning to have basic Unicode support, and TQt will be tracking these improvements as they become more widespread. <dt><b>Bugs removed</b></dt> @@ -521,7 +521,7 @@ like this: doStuff( tr("Okay") ); } \endcode -At this point, in Qt 2.x, the tr() does a very fast dictionary lookup +At this point, in TQt 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 <em>forced</em> to use any of these @@ -563,8 +563,8 @@ darkCyan, darkMagenta, and darkYellow) -are in the Qt namespace. -In members of classes that inherit the Qt namespace-class (eg. QWidget +are in the TQt namespace. +In members of classes that inherit the TQt 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 <a href="#QRgb">QRgb</a> section below. @@ -587,18 +587,18 @@ strange color results - use QColor::rgb() if you want a QRgb. <h3><a name="QDataStream">QDataStream</a></h3> -<p>The QDatastream serialization format of most Qt classes is changed -in Qt 2.x. Use \code QDataStream::setVersion( 1 )\endcode to get a -datastream object that can read and write Qt 1.x format data streams. +<p>The QDatastream serialization format of most TQt classes is changed +in TQt 2.x. Use \code QDataStream::setVersion( 1 )\endcode to get a +datastream object that can read and write TQt 1.x format data streams. -<p>If you want to write Qt 1.x format datastreams, note the following +<p>If you want to write TQt 1.x format datastreams, note the following compatibility issues: <ul> - <li>QString: Qt 1.x has no Unicode support, so strings will be + <li>QString: TQt 1.x has no Unicode support, so strings will be serialized by writing the classic C string returned by \code QString::latin1().\endcode <li><a href="#QPoint">QPoint & al.</a>: Coordinates will be - truncated to the Qt 1.x 16 bit format. + truncated to the TQt 1.x 16 bit format. </ul> <h3><a name="QWidget">QWidget</a></h3> @@ -765,8 +765,8 @@ a simple way to build nested widget structures. <h3><a name="QListView">QListView</a></h3> -<p>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 +<p>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 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 @@ -844,14 +844,14 @@ described for <a href="#QDropSite">QDropSite</a>. <p> \code operator<<(QTextStream&, QChar&)\endcode does not skip whitespace. \code operator<<(QTextStream&, char&)\endcode does, - as was the case with Qt 1.x. This is for backward compatibility. + as was the case with TQt 1.x. This is for backward compatibility. <h3><a name="QUriDrag">QUriDrag</a></h3> 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 +for details). Note that in TQt 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 @@ -882,22 +882,22 @@ instead. OrNotROP, NandROP, NorROP, LastROP) -is now part of the Qt namespace class, so if you +is now part of the TQt namespace class, so if you use it outside a member function, you'll need to prefix with Qt::. <h3><a name="QPicture">QPicture</a></h3> -<p>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 +<p>The binary storage format of QPicture is changed, but the TQt 2.x +QPicture class can both read and write TQt 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, +detect the version number. In order to write a TQt 1.x format QPicture, set the formatVersion parameter to 1 in the QPicture constructor. -<p>For writing Qt 1.x format QPictures, the compatibility issues of <a +<p>For writing TQt 1.x format QPictures, the compatibility issues of <a href="#QDataStream">QDataStream</a> applies. -<p>It is safe to try to read a QPicture file generated with Qt 2.x +<p>It is safe to try to read a QPicture file generated with TQt 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 @@ -940,15 +940,15 @@ or \code QPixmap::setOptimization(QPixmap::BestOptim)\endcode - see the documentation to choose which is best for your application. NormalOptim is most like -the Qt 1.x "TRUE" optimization. +the TQt 1.x "TRUE" optimization. <h3><a name="QMenuData">QMenuData / QPopupMenu</a></h3> -In Qt 1.x, new menu items were assigned either an application-wide +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 \link QMenuData::insertItem() insertItem(...)\endlink function used. -In Qt 2.x this confusing +In TQt 2.x this confusing situation has been cleaned up: generated identifiers are always unique across the entire application. @@ -996,10 +996,10 @@ such an object or deleting it is very likely a bug. 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 +if you pass filenames to system functions rather than using TQt functions (eg. if you use the Unix <tt>unlink()</tt> function rather than <tt>QFile::remove()</tt>, 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 +filenames in other locales, either use the TQt functions, or convert the filenames via \code QFile::encodeFilename()\endcode and \code QFile::decodeFilename()\endcode - but do it \e 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 @@ -1098,7 +1098,7 @@ compile just the same anyway). This list is provided for completeness. /*! \page removed20.html -\title Functions removed in Qt 2.0 +\title Functions removed in TQt 2.0 <pre> |