📄 porting.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Qt Toolkit - Porting to Qt 2.x</title><style type="text/css"><!--h3.fn,span.fn { margin-left: 1cm; text-indent: -1cm; }a:link { color: #004faf; text-decoration: none }a:visited { color: #672967; text-decoration: none }body { background: white; color: black; }--></style></head><body bgcolor="#ffffff"><p><table width="100%"><tr><td><a href="index.html"><img width="100" height="100" src="qtlogo.png"alt="Home" border="0"><img width="100"height="100" src="face.png" alt="Home" border="0"></a><td valign="top"><div align="right"><img src="dochead.png" width="472" height="27"><br><a href="classes.html"><b>Classes</b></a>- <a href="annotated.html">Annotated</a>- <a href="hierarchy.html">Tree</a>- <a href="functions.html">Functions</a>- <a href="index.html">Home</a>- <a href="topicals.html"><b>Structure</b> <font face="Arial,Helvetica,Geneva,Swiss,SunSans-Regular" align="center" size=32>Qte</font></a></div></table><h1 align="center"> Porting to Qt 2.x</h1><br clear="all"><p>You're probably looking at this page because you want to portyour application from Qt 1.x to Qt 2.x, but to be sure, let'sreview the good reasons to do this:<ul> <li>To get access to all the new Qt 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 colors and fonts and obey global system setting changes. <li>To stay up-to-date with the version of Qt 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 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 workwith Qt 2.x. Qt 2.x is also not completely <em>source</em> compatiblewith 1.x, however all points of incompatibility causecompiler errors (rather than mysterious results), or produce run-timemessages. The result is that Qt 2.x includes many additional features,discards obsolete functionality that is easily converted to use the newfeatures, and that porting an application from Qt 1.x to Qt 2.x isa simple task well worth the amount of effort required.<p>To port code using Qt 1.x to use Qt 2.x:<p><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 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. <li> If you get stuck, ask on the qt-interest mailing list, or Trolltech Technical Support if you're a Professional Edition licensee.</ul><p>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 consciousthat is the Qt Developer Community!</p><p><hr><p><h2 align=center>The Porting Notes</h2><p><ul> <li><b><a href="#Namespace">Namespace</a></b> <li><b><a href="#Virtual">Virtual Functions</a></b> <li><b><a href="#Collection">Collection classes</a></b> <li><b><a href="#DefaultParent">No Default 0 Parent Widget</a></b> <li><b><a href="#DebugVsRelease">Debug vs. Release</a></b><li><b><a href="#QApplication">QApplication</a></b> <li><b><a href="#QClipboard">QClipboard</a></b> <li><b><a href="#QColor">QColor</a></b> <li><b><a href="#QDataStream">QDataStream</a></b> <li><b><a href="#QDialog">QDialog</a></b> <li><b><a href="#QDropSite">QDropSite</a></b> <li><b><a href="#QEvent">QEvent</a></b> <li><b><a href="#QFile">QFile</a></b> <li><b><a href="#QFontMetrics">QFontMetrics</a></b> <li><b><a href="#QIODevice">QIODevice</a></b> <li><b><a href="#QLabel">QLabel</a></b> <li><b><a href="#QLayout">QLayout</a></b> <li><b><a href="#QListView">QListView</a></b> <li><b><a href="#QMenuData">QMenuData</a></b> <li><b><a href="#QMenuData">QPopupMenu</a></b> <li><b><a href="#QMultiLineEdit">QMultiLineEdit</a></b> <li><b><a href="#QPainter">QPainter</a></b> <li><b><a href="#QPicture">QPicture</a></b> <li><b><a href="#QPoint">QPoint, QPointArray, QSize and QRect</a></b> <li><b><a href="#QPixmap">QPixmap</a></b> <li><b><a href="#QRgb">QRgb</a></b> <li><b><a href="#QScrollView">QScrollView</a></b> <li><b><a href="#QStrList">QStrList</a></b> <li><b><a href="#QString">QString</a></b> <li><b><a href="#QTextStream">QTextStream</a></b> <li><b><a href="#QUriDrag">QUriDrag / QUrlDrag</a></b> <li><b><a href="#QValidator">QComboBox</a></b> <li><b><a href="#QValidator">QLineEdit</a></b> <li><b><a href="#QValidator">QSpinBox</a></b> <li><b><a href="#QValidator">QValidator</a></b> <li><b><a href="#QWidget">QWidget</a></b> <li><b><a href="#QWindow">QWindow</a></b></ul><p><hr><p><h3><a name=Namespace>Namespace</a></h3><p> Qt 2.x is namespace-clean, unlike 1.x. Qt now uses very fewglobal identifiers. Identifiers like <code>red, blue, LeftButton,AlignRight, Key_Up, Key_Down, NoBrush</code> etc. are now part of aspecial class <code>Qt</code> (defined in qnamespace.h),which is inherited bymost Qt 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,Qt::LeftButton, Qt::AlignRight</code>, etc.<p>The <code>qt/bin/qt20fix</code> script helps to fix the code thatneeds adaption, though most code does not need changing.<p>Compiling with -DQT1COMPATIBILITY will help you get going with Qt 2.x- it allows all the old "dirty namespace" identifiers from Qt 1.x tocontinue working. Without it, you'll get compile errors that caneasily be fixed by searching this page for the clean identifiers.<p><h3><a name=DefaultParent>No Default 0 Parent Widget</a></h3><p>In Qt 1.x, all widget constructors were defined with a default valueof 0 for the parent widget. However, only the main window of theapplication should be created with a 0 parent, all other widgetsshould have parents. Having the 0 default made it too simple to createbugs by forgetting to specify the parent of non-mainwindowwidgets. Such widgets would typically never be deleted (causing memoryleaks), and they would become top-level widgets, confusing the windowmanagers. Therefore, in Qt 2.x the 0 default parent has been removedfor the widget classes that are not likely to be used as main windows.<p>Note also that programs no longer need (or should) use 0 parent justto indicate that a widget should be top-level. See<pre> <a href="qwidget.html#17338a">QWidget::isTopLevel</a>()</pre> for details. See also the notes about<a href=#QMenuData>QPopupMenu</a> and <a href=#QDialog>QDialog</a>below.<p><h3><a name=Virtual>Virtual Functions</a></h3><p> Some virtual functions have changed signature in Qt 2.x.If you override them in derived classes, you must change the signatureof your functions accordingly.<p><!-- warwick can check for additions to this with his qt-2-report --><ul> <li><pre> <a href="qwidget.html#287f79">QWidget::setStyle</a>(GUIStyle)</pre><li><pre> <a href="qlistview.html#2323b8">QListView::addColumn</a>(const char *, int)</pre><li><pre> <a href="qlistview.html#251e98">QListView::setColumnText</a>(int, const char *)</pre><li><pre> <a href="qlistviewitem.html#808e84">QListViewItem::setText</a>(int, const char *)</pre><li><pre> <a href="qmultilineedit.html#e13115">QMultiLineEdit::insertLine</a>(const char *, int)</pre><li><pre> <a href="qmultilineedit.html#56c164">QMultiLineEdit::insertAt</a>(const char *, int, int, bool)</pre><li><pre> <a href="qspinbox.html#eccb7d">QSpinBox::setPrefix</a>(const char *)</pre><li><pre> <a href="qspinbox.html#36bd02">QSpinBox::setSuffix</a>(const char *)</pre><li><pre> <a href="qtoolbutton.html#51354a">QToolButton::setTextLabel</a>(const char *, bool)</pre><li><pre> <a href="qdoublevalidator.html#81476e">QDoubleValidator::validate</a>(<a href="qstring.html">QString</a> &, int &)</pre><li><pre> <a href="qintvalidator.html#91b7e2">QIntValidator::validate</a>(<a href="qstring.html">QString</a> &, int &)</pre><li><pre> <a href="qvalidator.html#3fa523">QValidator::fixup</a>(<a href="qstring.html">QString</a> &)</pre><li><pre> <a href="qslider.html#904afa">QSlider::paintSlider</a>(<a href="qpainter.html">QPainter</a> *, const QRect &)</pre><p></ul><p>This is one class of changes that arenot detected by the compiler,so you should mechanically search for each ofthese function names in your header files, eg.<p><pre>egrep -w 'setStyle|addColumn|setColumnText|setText...' *.h</pre><p>Of course, you'll get a few false positives (eg. if you have a setTextfunction that is not in a subclass of QListViewItem).<p><h3><a name=Collection>Collection classes</a></h3><p> The collection classes include genericclasses such as QGDict, QGList, andthe subclasses such as QDict and QList.<p> The macro-based Qt collection classes are obsolete; use thetemplate-based classes instead. Simply remove includes of qgeneric.h andreplace e.g. Q_DECLARE(QCache,QPixmap) with QCache<QPixmap>.<p> The GCI global typedef is replaced by QCollection::Item. Only if youmake your own subclasses of the undocumented generic collection classeswill you have GCI in your code.This change has been made to avoid collisions with other namespaces.<p> The GCF global typedef is removed (it was not used in Qt).<p><h3><a name=DebugVsRelease>Debug vs. Release</a></h3><p>The ASSERT macro is now a null expression if the CHECK_STATE flagis not set (i.e. if the NO_CHECK flag is defined).<p>The debug() function now outputs nothing if Qt was compiled withthe NO_DEBUG macro defined.<p><h3><a name=QString>QString</a></h3><p>QString has undergone major changes internally, and although it is highlybackward 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 ifyou use that you will incur a performance penalty since all Qt functionsthat took const char* now take const QString&.<p>To take full advantage of the new Internationalizationfunctionality in Qt 2.x, the following steps are required:<p> <ul> <li> Start converting all uses of "const char*" in parameters to "const QString&" - this can often be done mechanically, eg. using Perl. Convert usage of char[] for temporary string building to QString (much software already uses QString for this purpose as it offers many more facilities).<p> If you find that you are mixing usage of QCString, QString, and QByteArray, 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 QCString; if it is unterminated (ie. contains NULs) 8-bit data, use QByteArray; if it is text, use QString. </p><li> Put a breakpoint in <pre> <a href="qstring.html#ea8169">QString::latin1</a>()</pre><p> to catch places where Unicode information is being converted to ASCII (loosing information if your user in not using Latin1). Qt 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 <a href="i18n.html">Internationalization page</a> for information about the full process of internationalizing your software. </ul><p>Points to note about the new QString are:<p><dl compact><dt><b>Unicode</b></dt><dd> Qt 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, and ideally you'll only need latin1() or implicit conversion when interfacing to facilities that do not have Unicode support.<p><dt><b>Automatic-expanding</b></dt><dd>A big advantage of the new QString is that it automatically expandswhen you write to an indexed position.<p><dt><b>QChar and QCharRef</b></dt><dd>QChar are the Unicode characters that make up a QString. A QCharRef isa temporary reference to a QChar in a QString that when assigned toensures that the implicit sharing semantics of the QString are maintained.You are unlikely to use QCharRef in your own code - but so that youunderstand compiler error messages, just know that <tt>mystring[123]</tt>is a QCharRef whenever <tt>mystring</tt> is not a constant string. A QCharRefhas basically the same functionality as a QChar, except it is more restrictedin what you can assign to it and cast it to (to avoid programming errors).<p><dt><b>Use QString</b></dt><dd>Try to always use QString. If you <em>must</em>, use QCString which is theold implementation from Qt 1.x.<p><dt><b>Unicode vs. ASCII</b></dt><dd>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.<p><dt><b>Convertion to ASCII</b></dt><dd>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.<p><dt><b>QString is simpler</b></dt><dd>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.<p><dt><b>Some hacks don't work</b></dt><dd>This hack: use_sub_string( &my_string[index] ) should be replaced by: use_sub_string( my_string.mid(index) )<p><dt><b>QString(const char*, int) is removed</b></dt><dd>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.<p><dt><b>QString(int) is private</b></dt><dd>The QString constructor taking an integer is now private. This functionis not meaningful anymore, since QString does all space allocationautomatically. 99% of cases can simple be changed to use thedefault constructor, QString().<p>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 tocalling <pre> <a href="qstring.html#926f67">QString::sprintf</a>()</pre>. In Qt 2.x, the accidental bug case isprevented (you will get a compilation error) and QString::sprintf hasbeen made safe - you no longer need to pre-allocate space (though forother 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, whichwould usually give expected results in Qt 1.x. For Qt 2.x the correctsyntax is to use QString::null, though note thatthe default constructor, QString(), creates a null string too.Assignment of 0 to a QString is ambiguous - assignQString::null; you'll mainly find these in code that has been convertedfrom const char* types to QString.This also prevents a common error case from Qt 1.x - in⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -