Update to latest tqt3 automated conversion

1 files changed, 100 insertions, 100 deletions

diff --git a/doc/html/porting2.html b/doc/html/porting2.html
index 723a4e0a0..0276d068b 100644
--- a/doc/html/porting2.html
+++ b/doc/html/porting2.html
@@ -107,7 +107,7 @@ that is the TQt Developer Community!
 <li><b><a href="#TQMultiLineEdit">TQMultiLineEdit</a></b>
 <li><b><a href="#TQPainter">TQPainter</a></b>
 <li><b><a href="#TQPicture">TQPicture</a></b>
-<li><b><a href="#TQPoint">TQPoint, <a href="qpointarray.html">TQPointArray</a>, <a href="qsize.html">TQSize</a> and <a href="qrect.html">TQRect</a></a></b>
+<li><b><a href="#TQPoint">TQPoint, <a href="ntqpointarray.html">TQPointArray</a>, <a href="ntqsize.html">TQSize</a> and <a href="ntqrect.html">TQRect</a></a></b>
 <li><b><a href="#TQPixmap">TQPixmap</a></b>
 <li><b><a href="#TQRgb">TQRgb</a></b>
 <li><b><a href="#TQScrollView">TQScrollView</a></b>
@@ -127,9 +127,9 @@ that is the TQt Developer Community!
 <p> <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>TQt</code> (defined in qnamespace.h),
+special class <code>TQt</code> (defined in ntqnamespace.h),
 which is inherited by
-most TQt classes.  Member functions of classes that inherit from <a href="qwidget.html">TQWidget</a>,
+most TQt classes.  Member functions of classes that inherit from <a href="ntqwidget.html">TQWidget</a>,
 etc. are totally unaffected, but code that is
 <em>not</em> in functions of classes inherited from <code>TQt</code>,
 you must qualify these identifiers like this: <code>TQt::red,
@@ -186,7 +186,7 @@ of your functions accordingly.
  
 <li><pre> TQValidator::fixup(TQString &amp;)</pre>
  
-<li><pre> TQSlider::paintSlider(TQPainter *, const <a href="qrect.html">TQRect</a> &amp;)</pre>
+<li><pre> TQSlider::paintSlider(TQPainter *, const <a href="ntqrect.html">TQRect</a> &amp;)</pre>
  
 </ul>
 <p> This is one class of changes that are
@@ -202,10 +202,10 @@ function that is not in a subclass of <a href="qlistviewitem.html">TQListViewIte
 <p> <h3><a name="Collection">Collection classes</a></h3>
 <p> <p> The <a href="collection.html#collection-classes">collection classes</a> include generic
 classes such as TQGDict, TQGList, and
-the subclasses such as <a href="qdict.html">TQDict</a> and TQList.
+the subclasses such as <a href="ntqdict.html">TQDict</a> and TQList.
 <p> <p> 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(<a href="qcache.html">TQCache</a>,TQPixmap) with TQCache<TQPixmap>.
+template-based classes instead. Simply remove includes of ntqgeneric.h and
+replace e.g. Q_DECLARE(<a href="ntqcache.html">TQCache</a>,TQPixmap) with TQCache<TQPixmap>.
 <p> <p> 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.
@@ -217,9 +217,9 @@ is not set (i.e. if the QT_NO_CHECK flag is defined).
 <p> <p>The debug() function now outputs nothing if TQt was compiled with
 the QT_NO_DEBUG macro defined.
 <p> <h3><a name="TQString">TQString</a></h3>
-<p> <a href="qstring.html">TQString</a> has undergone major changes internally, and although it is highly
+<p> <a href="ntqstring.html">TQString</a> 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 <a href="qcstring.html">TQCString</a> in TQt 2.x, though if
+The TQt 1.x TQString class has been renamed to <a href="ntqcstring.html">TQCString</a> 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&.
 <p> <p>
@@ -237,7 +237,7 @@ 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 <a href="qstring.html">TQString</a>.
+use <a href="ntqstring.html">TQString</a>.
 </p>
 <li> Put a breakpoint in <pre> TQString::latin1()</pre>
  
@@ -268,7 +268,7 @@ 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 <a href="qstring.html">TQString</a> is that it automatically expands
+A big advantage of the new <a href="ntqstring.html">TQString</a> is that it automatically expands
 when you write to an indexed position.
 <p> <dt><b>TQChar and <a href="qcharref.html">TQCharRef</a></b></dt>
 <dd>
@@ -282,11 +282,11 @@ 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).
 <p> <dt><b>Use TQString</b></dt>
 <dd>
-Try to always use TQString.  If you <em>must</em>, use <a href="qcstring.html">TQCString</a> which is the
+Try to always use TQString.  If you <em>must</em>, use <a href="ntqcstring.html">TQCString</a> which is the
 old implementation from TQt 1.x.
 <p> <dt><b>Unicode vs. ASCII</b></dt>
 <dd>
-Every conversion to and from ASCII is wasted time, so try to use <a href="qstring.html">TQString</a>
+Every conversion to and from ASCII is wasted time, so try to use <a href="ntqstring.html">TQString</a>
 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>
@@ -309,11 +309,11 @@ use_sub_string( my_string.mid(index) )
 <dd>
 The TQString constructor taking a const char* and an integer is removed.
 Use of this constructor was error-prone, since the length included the
-'&#92;0' terminator. Use <a href="qstring.html#left">TQString::left</a>(int) or <a href="qstring.html#fromLatin1">TQString::fromLatin1</a>( const char*,
+'&#92;0' terminator. Use <a href="ntqstring.html#left">TQString::left</a>(int) or <a href="ntqstring.html#fromLatin1">TQString::fromLatin1</a>( const char*,
 int ) -- in both cases the int parameter signifies the number of characters.
 <p> <dt><b>TQString(int) is private</b></dt>
 <dd>
-The <a href="qstring.html">TQString</a> constructor taking an integer is now private.  This function
+The <a href="ntqstring.html">TQString</a> 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().
@@ -328,9 +328,9 @@ 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 <a href="qstring.html#TQString-null">TQString::null</a>, though note that
+syntax is to use <a href="ntqstring.html#TQString-null">TQString::null</a>, though note that
 the default constructor, TQString(), creates a null string too.
-Assignment of 0 to a <a href="qstring.html">TQString</a> is ambiguous - assign
+Assignment of 0 to a <a href="ntqstring.html">TQString</a> 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
@@ -356,28 +356,28 @@ summary of how much your application is doing Unicode and ASCII
 back-and-forth conversions.
 <p> <dt><b>TQString::detach() is obsolete and removed</b></dt>
 <dd>
-Since <a href="qstring.html">TQString</a> is now always shared, this function does nothing.
+Since <a href="ntqstring.html">TQString</a> is now always shared, this function does nothing.
 Remove calls to TQString::detach().
 <p> <dt><b>TQString::resize(int size) is obsolete and removed</b></dt>
 <dd>
 Code using this to truncate a string should use
-<a href="qstring.html#truncate">truncate(size-1)</a>.
+<a href="ntqstring.html#truncate">truncate(size-1)</a>.
 Code using qstr.resize(0) should use qstr = TQString::null.
 Code calling resize(n) prior to using
-<a href="qstring.html#operator[]">operator[]</a> up to n just remove
+<a href="ntqstring.html#operator[]">operator[]</a> up to n just remove
 the resize(n) completely.
 <p> <dt><b>TQString::size() is obsolete and removed</b></dt>
 <dd>
 Calls to this function must be replaced by
-<a href="qstring.html#length">length()</a>+1.
+<a href="ntqstring.html#length">length()</a>+1.
 <p> <dt><b>TQString::setStr(const char*) is removed</b></dt>
 <dd>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
-<a href="qbytearray.html">TQByteArray</a> or <a href="qcstring.html">TQCString</a> instead.
+<a href="qbytearray.html">TQByteArray</a> or <a href="ntqcstring.html">TQCString</a> instead.
 <p> <dt><b>TQString is not an array of bytes</b></dt>
 <dd>
-Code that uses <a href="qstring.html">TQString</a> as an array of bytes should use TQByteArray
+Code that uses <a href="ntqstring.html">TQString</a> as an array of bytes should use TQByteArray
 or a char[], <em>then</em> convert that to a TQString if needed.
 <p> <dt><b>"string = 0"</b></dt>
 <dd>
@@ -406,26 +406,26 @@ where you would have used 0 with char pointers.
 This means that inserting a 0-character
 in the middle of the string does <em>not</em> change the length().  ie.
 <pre>
-   <a href="qstring.html">TQString</a> s = "fred";
+   <a href="ntqstring.html">TQString</a> s = "fred";
    s[1] = '\0';
-     // s.<a href="qstring.html#length">length</a>() == 4
+     // s.<a href="ntqstring.html#length">length</a>() == 4
      // s == "f\0ed"
-     // s.<a href="qstring.html#latin1">latin1</a>() == "f"
+     // s.<a href="ntqstring.html#latin1">latin1</a>() == "f"
    s[1] = 'r';
      // s == "fred"
-     // s.<a href="qstring.html#latin1">latin1</a>() == "fred"
+     // s.<a href="ntqstring.html#latin1">latin1</a>() == "fred"
  </pre>
  
 Especially look out for this type of code:
 <pre>
-   <a href="qstring.html">TQString</a> s(2);
+   <a href="ntqstring.html">TQString</a> s(2);
    s[0] = '?';
    s[1] = 0;
  </pre>
  
 This creates a string 2 characters long.
 To find these problems while converting, you might like to
-add <a href="qapplication.html#Q_ASSERT">Q_ASSERT</a>(strlen(d->ascii)==d->len) inside
+add <a href="ntqapplication.html#Q_ASSERT">Q_ASSERT</a>(strlen(d->ascii)==d->len) inside
 <pre> TQString::latin1()</pre>
  .
 <p> <dt><b>TQString or Standard C++ string?</b></dt>
@@ -436,10 +436,10 @@ 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 <em>the norm</em>
 do programmers find them usable. Though it is possible to convert between
-string and <a href="qstring.html">TQString</a>, it is less efficient than using TQString throughout.
+string and <a href="ntqstring.html">TQString</a>, it is less efficient than using TQString throughout.
 For example, when using:
 <pre>
-    TQLabel::<a href="qlabel.html#setText">setText</a>( const <a href="qstring.html">TQString</a>&amp; )
+    TQLabel::<a href="ntqlabel.html#setText">setText</a>( const <a href="ntqstring.html">TQString</a>&amp; )
 </pre>
  
 if you use string, like this:
@@ -453,13 +453,13 @@ if you use string, like this:
 that will create a (ASCII only) copy of str, stored in mylabel.
 But this:
 <pre>
-    void myclass::dostuffwithtext( const <a href="qstring.html">TQString</a>&amp; str )
+    void myclass::dostuffwithtext( const <a href="ntqstring.html">TQString</a>&amp; str )
     {
         mylabel.setText( str );
     }
 </pre>
  
-will make an <a href="shclass.html#implicitly-shared">implicitly shared</a> reference to str in the <a href="qlabel.html">TQLabel</a> - no copying
+will make an <a href="shclass.html#implicitly-shared">implicitly shared</a> reference to str in the <a href="ntqlabel.html">TQLabel</a> - no copying
 at all.  This function might be 10 nested function calls away from something
 like this:
 <pre>
@@ -470,7 +470,7 @@ like this:
 </pre>
  
 At this point, in TQt 2.x, the tr() does a very fast dictionary lookup
-through memory-mapped message files, returning some Unicode <a href="qstring.html">TQString</a> for
+through memory-mapped message files, returning some Unicode <a href="ntqstring.html">TQString</a> for
 the appropriate language (the default being to just make a TQString out
 of the text, of course - you're not <em>forced</em> to use any of these
 features), and that <em>same</em> memory mapped Unicode will be passed
@@ -505,7 +505,7 @@ darkMagenta,
 and
 darkYellow)
 are in the TQt namespace.
-In members of classes that inherit the TQt namespace-class (eg. <a href="qwidget.html">TQWidget</a>
+In members of classes that inherit the TQt namespace-class (eg. <a href="ntqwidget.html">TQWidget</a>
 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 <a href="#TQRgb">TQRgb</a> section below.
@@ -515,13 +515,13 @@ 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 <a href="qcolor.html#qRgb">qRgb</a>(int r,int g,int b) and the
-access functions <a href="qcolor.html#qRed">qRed</a>(TQRgb), <a href="qcolor.html#qBlue">qBlue</a>(TQRgb), and <a href="qcolor.html#qGreen">qGreen</a>(TQRgb).
+creator function <a href="ntqcolor.html#qRgb">qRgb</a>(int r,int g,int b) and the
+access functions <a href="ntqcolor.html#qRed">qRed</a>(TQRgb), <a href="ntqcolor.html#qBlue">qBlue</a>(TQRgb), and <a href="ntqcolor.html#qGreen">qGreen</a>(TQRgb).
 If you are using the alpha channel, it hasn't moved, but you should use
-the functions <a href="qcolor.html#qRgba">qRgba</a>(int,int,int,int) and <a href="qcolor.html#qAlpha">qAlpha</a>(TQRgb). Note also that
-<a href="qcolor.html#pixel">TQColor::pixel</a>() does <i>not</i> return a TQRgb (it never did on all platforms,
+the functions <a href="ntqcolor.html#qRgba">qRgba</a>(int,int,int,int) and <a href="ntqcolor.html#qAlpha">qAlpha</a>(TQRgb). Note also that
+<a href="ntqcolor.html#pixel">TQColor::pixel</a>() does <i>not</i> 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 <a href="qcolor.html#rgb">TQColor::rgb</a>() if you want a TQRgb.
+strange color results - use <a href="ntqcolor.html#rgb">TQColor::rgb</a>() if you want a TQRgb.
 <p> <h3><a name="TQDataStream">TQDataStream</a></h3>
 <p> <p>The TQDatastream serialization format of most TQt classes is changed
 in TQt 2.x. Use <pre> TQDataStream::setVersion( 1 )</pre>
@@ -532,7 +532,7 @@ compatibility issues:
 <ul>
 <li>TQString: TQt 1.x has no Unicode support, so strings will be
 serialized by writing the classic C string returned by <pre>
-        TQString::<a href="qstring.html#latin1">latin1</a>().</pre>
+        TQString::<a href="ntqstring.html#latin1">latin1</a>().</pre>
  
 <li><a href="#TQPoint">TQPoint & al.</a>: Coordinates will be
 truncated to the TQt 1.x 16 bit format.
@@ -540,7 +540,7 @@ truncated to the TQt 1.x 16 bit format.
 <p> <h3><a name="TQWidget">TQWidget</a></h3>
 <p> <h4>TQWidget::recreate()</h4>
 <p>
-This function is now called <a href="qwidget.html#reparent">reparent()</a>.
+This function is now called <a href="ntqwidget.html#reparent">reparent()</a>.
 <p> <h4>TQWidget::setAcceptFocus(bool)</h4>
 <p>
 This function is removed.
@@ -562,14 +562,14 @@ 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
-<a href="qpainter.html#setClipRegion">TQPainter::setClipRegion</a>() superfluous. Apart from the improved
+<a href="ntqpainter.html#setClipRegion">TQPainter::setClipRegion</a>() superfluous. Apart from the improved
 consistency, the change is likely to reduce flicker and to make TQt
 event slightly faster.
 <p> <h3><a name="TQIODevice">TQIODevice</a></h3>
 <p>
 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 <a href="qiodevice.html">TQIODevice</a>,
+#define index to strchr.  If you have made a subclass of <a href="ntqiodevice.html">TQIODevice</a>,
 check every occurrence of the string "index" in the implementation, since
 a compiler will not always catch cases like <pre>(uint)index</pre>
  
@@ -585,7 +585,7 @@ have been renamed to <pre> TQLabel::setIndent()</pre>
   and
 <pre> TQLabel::indent()</pre>
  , respectively. This was done to avoid
-collision with <a href="qframe.html#setMargin">TQFrame::setMargin</a>(), which is now virtual.
+collision with <a href="ntqframe.html#setMargin">TQFrame::setMargin</a>(), which is now virtual.
 <p> <h4><pre> TQLabel::setMovie()</pre>
  </h4>
 <p>
@@ -607,24 +607,24 @@ 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
-<a href="qdialog.html#TQDialog">TQDialog::TQDialog</a>() conditional on parent not being 0.
+<a href="ntqdialog.html#TQDialog">TQDialog::TQDialog</a>() conditional on parent not being 0.
 <p> <h3><a name="TQStrList">TQStrList</a></h3>
-<p> Many methods that took a <a href="qstrlist.html">TQStrList</a> can now instead take a <a href="qstringlist.html">TQStringList</a>,
-which is a real list of <a href="qstring.html">TQString</a> values.
+<p> Many methods that took a <a href="ntqstrlist.html">TQStrList</a> can now instead take a <a href="ntqstringlist.html">TQStringList</a>,
+which is a real list of <a href="ntqstring.html">TQString</a> values.
 <p> To use TQStringList rather than TQStrList, change loops that look like this:
 <pre>
-    <a href="qstrlist.html">TQStrList</a> list = ...;
+    <a href="ntqstrlist.html">TQStrList</a> list = ...;
     const char* s;
-    for ( s = list.<a href="qptrlist.html#first">first</a>(); s; s = list.<a href="qptrlist.html#next">next</a>() ) {
+    for ( s = list.<a href="ntqptrlist.html#first">first</a>(); s; s = list.<a href="ntqptrlist.html#next">next</a>() ) {
         process(s);
     }
 </pre>
  
 to be like this:
 <pre>
-    <a href="qstringlist.html">TQStringList</a> list = ...;
+    <a href="ntqstringlist.html">TQStringList</a> list = ...;
     TQStringList::ConstIterator i;
-    for ( i = list.<a href="qvaluelist.html#begin">begin</a>(); i != list.<a href="qvaluelist.html#end">end</a>(); ++i ) {
+    for ( i = list.<a href="ntqvaluelist.html#begin">begin</a>(); i != list.<a href="ntqvaluelist.html#end">end</a>(); ++i ) {
         process(*i);
     }
 </pre>
@@ -633,14 +633,14 @@ to be like this:
 <p> The following functions now use TQStringList rather than TQStrList
 for return types/parameters.
 <p> <ul>
-<li><tt>void <a href="qfiledialog.html#setFilters">TQFileDialog::setFilters</a>(const <a href="qstrlist.html">TQStrList</a>&)</tt>
-becomes <tt>void TQFileDialog::setFilters(const <a href="qstringlist.html">TQStringList</a>&)</tt>
-<li><tt>TQStrList <a href="qfiledialog.html#getOpenFileNames">TQFileDialog::getOpenFileNames</a>(...)</tt>
+<li><tt>void <a href="ntqfiledialog.html#setFilters">TQFileDialog::setFilters</a>(const <a href="ntqstrlist.html">TQStrList</a>&)</tt>
+becomes <tt>void TQFileDialog::setFilters(const <a href="ntqstringlist.html">TQStringList</a>&)</tt>
+<li><tt>TQStrList <a href="ntqfiledialog.html#getOpenFileNames">TQFileDialog::getOpenFileNames</a>(...)</tt>
 becomes <tt>TQStringList TQFileDialog::getOpenFileNames(...)</tt>
 <li><tt>bool TQUrlDrag::decodeLocalFiles(<a href="qmimesource.html">TQMimeSource</a>*, TQStrList&)</tt>
 becomes <tt>bool <a href="quridrag.html#decodeLocalFiles">TQUriDrag::decodeLocalFiles</a>(TQMimeSource*, TQStringList&)</tt>
 <li><tt>const TQStrList *TQDir::entryList(...) const</tt>
-becomes <tt>TQStringList <a href="qdir.html#entryList">TQDir::entryList</a>(...) const</tt>
+becomes <tt>TQStringList <a href="ntqdir.html#entryList">TQDir::entryList</a>(...) const</tt>
 (note that the return type is no longer a pointer).  You may also
 choose to use encodedEntryList().
 </ul>
@@ -650,13 +650,13 @@ choose to use encodedEntryList().
 <li><tt>TQListBox::insertStringList(const TQStringList &,int index=-1)</tt>
 </ul>
 <p> The rarely used static function <tt>void
-TQFont::listSubstitutions(<a href="qstrlist.html">TQStrList</a>*)</tt> is replaced by <tt>TQStringList
-<a href="qfont.html#substitutions">TQFont::substitutions</a>()</tt>.
+TQFont::listSubstitutions(<a href="ntqstrlist.html">TQStrList</a>*)</tt> is replaced by <tt>TQStringList
+<a href="ntqfont.html#substitutions">TQFont::substitutions</a>()</tt>.
 <p> <h3><a name="TQLayout">TQLayout</a></h3>
 <p> <p> 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
-<a href="qwidget.html#sizeHint">sizeHint()</a>.
-<p> <p> The default implementation of <a href="qwidget.html#sizeHint">TQWidget::sizeHint</a>() will no longer
+<a href="ntqwidget.html#sizeHint">sizeHint()</a>.
+<p> <p> The default implementation of <a href="ntqwidget.html#sizeHint">TQWidget::sizeHint</a>() will no longer
 return just an invalid size; if the widget has a layout, it will return
 the layout's preferred size.
 <p> <p> The special maximum MaximumHeight/Width is now TQWIDGETSIZE_MAX,
@@ -667,32 +667,32 @@ 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.)
-<p> <p> The class TQGManager is removed. Subclasses of <a href="qlayout.html">TQLayout</a> need to be rewritten
-to use the new, much simpler <a href="qlayout.html">TQLayout API</a>.
+<p> <p> The class TQGManager is removed. Subclasses of <a href="ntqlayout.html">TQLayout</a> need to be rewritten
+to use the new, much simpler <a href="ntqlayout.html">TQLayout API</a>.
 <p> <p> For typical layouts, all use of
-<a href="qwidget.html#setMinimumSize">setMinimumSize()</a>
+<a href="ntqwidget.html#setMinimumSize">setMinimumSize()</a>
 and
-<a href="qwidget.html#setFixedSize">setFixedSize()</a>
+<a href="ntqwidget.html#setFixedSize">setFixedSize()</a>
 can be removed.
-<a href="qlayout.html#activate">activate()</a> is no longer necessary.
+<a href="ntqlayout.html#activate">activate()</a> is no longer necessary.
 <p> <p>
-You might like to look at the <a href="qgrid.html">TQGrid</a>, <a href="qvbox.html">TQVBox</a>, and <a href="qhbox.html">TQHBox</a> widgets - they offer
+You might like to look at the <a href="ntqgrid.html">TQGrid</a>, <a href="ntqvbox.html">TQVBox</a>, and <a href="ntqhbox.html">TQHBox</a> widgets - they offer
 a simple way to build nested widget structures.
 <p> <h3><a name="TQListView">TQListView</a></h3>
 <p> <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 <a href="qscrollview.html">TQScrollView</a> where mouse (and other position-oriented) events are
+in <a href="ntqscrollview.html">TQScrollView</a> 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(),
-<a href="qwidget.html#mouseDoubleClickEvent">TQListView::mouseDoubleClickEvent</a>(), <a href="qwidget.html#mouseMoveEvent">TQListView::mouseMoveEvent</a>(), or
-<a href="qwidget.html#mouseReleaseEvent">TQListView::mouseReleaseEvent</a>() you must instead override
+<a href="ntqwidget.html#mouseDoubleClickEvent">TQListView::mouseDoubleClickEvent</a>(), <a href="ntqwidget.html#mouseMoveEvent">TQListView::mouseMoveEvent</a>(), or
+<a href="ntqwidget.html#mouseReleaseEvent">TQListView::mouseReleaseEvent</a>() you must instead override
 viewportMousePressEvent(),
 viewportMouseDoubleClickEvent(), viewportMouseMoveEvent(), or
 viewportMouseReleaseEvent() respectively.  New code will usually override
 contentsMousePressEvent() etc.
-<p> <p>The signal <a href="qlistview.html#selectionChanged">TQListView::selectionChanged</a>(<a href="qlistviewitem.html">TQListViewItem</a> *) can now be
+<p> <p>The signal <a href="ntqlistview.html#selectionChanged">TQListView::selectionChanged</a>(<a href="qlistviewitem.html">TQListViewItem</a> *) can now be
 emitted with a null pointer as parameter. Programs that use the
 argument without checking for 0, may crash.
 <p> <h3><a name="TQMultiLineEdit">TQMultiLineEdit</a></h3>
@@ -701,45 +701,45 @@ The protected function
 <pre> TQMultiLineEdit::textWidth(TQString*)</pre>
  
 changed to
-<pre> TQMultiLineEdit::textWidth(const <a href="qstring.html">TQString</a>&amp;)</pre>
+<pre> TQMultiLineEdit::textWidth(const <a href="ntqstring.html">TQString</a>&amp;)</pre>
  .
 This is unlikely to be a problem, and you'll get a compile error
 if you called it.
 <p> <h3><a name="TQClipboard">TQClipboard</a></h3>
 <p> <p>
 <pre> TQClipboard::pixmap()</pre>
-  now returns a <a href="qpixmap.html">TQPixmap</a>, not a TQPixmap*.
+  now returns a <a href="ntqpixmap.html">TQPixmap</a>, not a TQPixmap*.
 The pixmap
-will be <a href="qpixmap.html#isNull">null</a> if no pixmap is on the
-clipboard.  <a href="qclipboard.html">TQClipboard</a> now offers powerful MIME-based types on the
+will be <a href="ntqpixmap.html#isNull">null</a> if no pixmap is on the
+clipboard.  <a href="ntqclipboard.html">TQClipboard</a> 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).
 <p> <h3><a name="TQDropSite">TQDropSite</a></h3>
 <p> <P>
 TQDropSite is obsolete.  If you simply passed <tt>this</tt>, just remove
 the inheritance of TQDropSite and call
-<a href="qwidget.html#setAcceptDrops">setAcceptDrops(TRUE)</a> in the class
+<a href="ntqwidget.html#setAcceptDrops">setAcceptDrops(TRUE)</a> in the class
 constructor.
 If you passed something other than <tt>this</tt>,
 your code will not work.  A common case is passing
 the
-<a href="qscrollview.html#viewport">viewport()</a> of a <a href="qlistview.html">TQListView</a>,
+<a href="ntqscrollview.html#viewport">viewport()</a> of a <a href="ntqlistview.html">TQListView</a>,
 in which case,
 override the
-<a href="qscrollview.html#contentsDragMoveEvent">contentsDragMoveEvent()</a>,
+<a href="ntqscrollview.html#contentsDragMoveEvent">contentsDragMoveEvent()</a>,
 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).
 <p> <h3><a name="TQScrollView">TQScrollView</a></h3>
 <p> The parameters in the signal
-<a href="qscrollview.html#contentsMoving">contentsMoving(int,int)</a>
+<a href="ntqscrollview.html#contentsMoving">contentsMoving(int,int)</a>
 are now positive rather than negative values, coinciding with
-<a href="qscrollview.html#setContentsPos">setContentsPos()</a>.  Search for
+<a href="ntqscrollview.html#setContentsPos">setContentsPos()</a>.  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.
-<p> If you used drag and drop with <a href="qscrollview.html">TQScrollView</a>, you may experience the problem
+<p> If you used drag and drop with <a href="ntqscrollview.html">TQScrollView</a>, you may experience the problem
 described for <a href="#TQDropSite">TQDropSite</a>.
 <p> <h3><a name="TQTextStream">TQTextStream</a></h3>
 <p> <p>
@@ -759,7 +759,7 @@ identifiers affected by the Url to Uri change are
 TQUrlDrag::setUrls() and TQUrlDrag::urlToLocalFile().
 <p> <h3><a name="TQPainter">TQPainter</a></h3>
 <p> <p> The GrayText painter flag has been removed. Use
-<a href="qpainter.html#setPen">setPen( palette().disabled().foreground() )</a>
+<a href="ntqpainter.html#setPen">setPen( palette().disabled().foreground() )</a>
 instead.
 <p> <p> The RasterOp enum
 (CopyROP,
@@ -782,7 +782,7 @@ 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::.
 <p> <h3><a name="TQPicture">TQPicture</a></h3>
-<p> <p>The binary storage format of <a href="qpicture.html">TQPicture</a> is changed, but the TQt 2.x
+<p> <p>The binary storage format of <a href="ntqpicture.html">TQPicture</a> is changed, but the TQt 2.x
 TQPicture class can both read and write TQt 1.x format TQPictures. No
 special handling is required for reading; TQPicture will automatically
 detect the version number. In order to write a TQt 1.x format TQPicture,
@@ -794,11 +794,11 @@ href="#TQDataStream">TQDataStream</a> applies.
 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.
-<p> <h3><a name="TQPoint">TQPoint, <a href="qpointarray.html">TQPointArray</a>, <a href="qsize.html">TQSize</a> and <a href="qrect.html">TQRect</a></a></h3>
+<p> <h3><a name="TQPoint">TQPoint, <a href="ntqpointarray.html">TQPointArray</a>, <a href="ntqsize.html">TQSize</a> and <a href="ntqrect.html">TQRect</a></a></h3>
 <p> <p>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.
-<p> <p>TQPointArray is now actually, not only seemingly, a TQArray of <a href="qpoint.html">TQPoint</a>
+<p> <p>TQPointArray is now actually, not only seemingly, a TQArray of <a href="ntqpoint.html">TQPoint</a>
 objects. The semi-internal workaround classes TQPointData and TQPointVal
 are removed since they are no longer needed; TQPoint is used directly
 instead. The function <pre> TQPointArray::shortPoints()</pre>
@@ -806,7 +806,7 @@ instead. The function <pre> TQPointArray::shortPoints()</pre>
 provides the point array converted to short (16bit) coordinates for
 use with external functions that demand that format.
 <p> <h3><a name="TQImage">TQImage</a></h3>
-<p> <a href="qimage.html">TQImage</a> uses TQRgb for the colors - see <a href="#TQRgb">the changes to that</a>.
+<p> <a href="ntqimage.html">TQImage</a> uses TQRgb for the colors - see <a href="#TQRgb">the changes to that</a>.
 <p> <h3><a name="TQPixmap">TQPixmap</a></h3>
 <p> <pre> TQPixmap::convertToImage()</pre>
   with bitmaps now guarantees that color0 pixels
@@ -826,10 +826,10 @@ or
 - see the documentation
 to choose which is best for your application.  NormalOptim is most like
 the TQt 1.x "TRUE" optimization.
-<p> <h3><a name="TQMenuData">TQMenuData / <a href="qpopupmenu.html">TQPopupMenu</a></a></h3>
+<p> <h3><a name="TQMenuData">TQMenuData / <a href="ntqpopupmenu.html">TQPopupMenu</a></a></h3>
 <p> 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
-<a href="qmenudata.html#insertItem">insertItem(...)</a> function used.
+<a href="ntqmenudata.html#insertItem">insertItem(...)</a> function used.
 In TQt 2.x this confusing
 situation has been cleaned up: generated identifiers are always
 unique across the entire application.
@@ -850,27 +850,27 @@ ownership manually.
 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.
-<p> Last but not least, <a href="qpopupmenu.html">TQPopupMenu</a> no longer inherits TQTableView. Instead,
-it directly inherits <a href="qframe.html">TQFrame</a>.
-<p> <h3><a name="TQValidator">TQValidator (<a href="qlineedit.html">TQLineEdit</a>, <a href="qcombobox.html">TQComboBox</a>, <a href="qspinbox.html">TQSpinBox</a>) </a></h3>
+<p> Last but not least, <a href="ntqpopupmenu.html">TQPopupMenu</a> no longer inherits TQTableView. Instead,
+it directly inherits <a href="ntqframe.html">TQFrame</a>.
+<p> <h3><a name="TQValidator">TQValidator (<a href="ntqlineedit.html">TQLineEdit</a>, <a href="ntqcombobox.html">TQComboBox</a>, <a href="ntqspinbox.html">TQSpinBox</a>) </a></h3>
 <p> <pre> TQValidator::validate(...)</pre>
  
 and
-<pre> TQValidator::fixup( <a href="qstring.html">TQString</a> &amp; )</pre>
+<pre> TQValidator::fixup( <a href="ntqstring.html">TQString</a> &amp; )</pre>
  
 are now const
 functions. If your subclass reimplements validate() as a
 non-const function,
 you will get a compile error (validate was pure virtual).
 <p> In TQLineEdit, TQComboBox, and TQSpinBox,
-setValidator(...) now takes a const pointer to a <a href="qvalidator.html">TQValidator</a>, and
+setValidator(...) now takes a const pointer to a <a href="ntqvalidator.html">TQValidator</a>, 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 <a href="qobject.html">TQObject</a> on its own, with its own parent - you can easily set the same validator
+a <a href="ntqobject.html">TQObject</a> 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.
-<p> <h3><a name="TQFile">TQFile, <a href="qfileinfo.html">TQFileInfo</a>, <a href="qdir.html">TQDir</a></a></h3>
-<p> File and directory names are now always Unicode strings (ie. <a href="qstring.html">TQString</a>).  If you used TQString
+<p> <h3><a name="TQFile">TQFile, <a href="ntqfileinfo.html">TQFileInfo</a>, <a href="ntqdir.html">TQDir</a></a></h3>
+<p> File and directory names are now always Unicode strings (ie. <a href="ntqstring.html">TQString</a>).  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 <tt>unlink()</tt> function rather than <tt>TQFile::remove()</tt>, your code will probably
@@ -888,12 +888,12 @@ boundingRect(<a href="qchar.html">TQChar</a>), but since
 char auto-converts to TQChar, you're not likely to run into problems
 with this.
 <p> <h3><a name="TQWindow">TQWindow</a></h3>
-<p> This class (which was just <a href="qwidget.html">TQWidget</a> under a different name) has been
+<p> This class (which was just <a href="ntqwidget.html">TQWidget</a> under a different name) has been
 removed.  If you used it, do a global search-and-replace of the word
 "TQWindow" with "TQWidget".
 <p> <h3><a name="TQEvent">TQEvent</a></h3>
-<p> <p> The global #define macros in qevent.h have been replaced by an
-enum in <a href="qevent.html">TQEvent</a>.  Use e.g. TQEvent::Paint instead of Event_Paint. Same
+<p> <p> The global #define macros in ntqevent.h have been replaced by an
+enum in <a href="ntqevent.html">TQEvent</a>.  Use e.g. TQEvent::Paint instead of Event_Paint. Same
 for all of:
 Event_None,
 Event_Timer,
@@ -931,7 +931,7 @@ Event_ActivateControl,
 Event_DeactivateControl,
 and
 Event_User.
-<p> <p> The Q_*_EVENT macros in qevent.h have been deleted.  Use an
+<p> <p> The Q_*_EVENT macros in ntqevent.h have been deleted.  Use an
 explicit cast instead. The macros were:
 Q_TIMER_EVENT,
 Q_MOUSE_EVENT,
@@ -951,7 +951,7 @@ much testing of its values.
 <p> <h3>All the removed functions</h3>
 <p> All <a href="removed20.html">these functions</a> have been removed in
 TQt 2.x.  Most are simply cases where "const char*" has changed to
-"const <a href="qstring.html">TQString</a>&", or when an enumeration type has moved into the TQt::
+"const <a href="ntqstring.html">TQString</a>&", 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.
 <p>