1 files changed, 32 insertions, 32 deletions
diff --git a/python/pykde/doc/limits.html b/python/pykde/doc/limits.html
index 3316c8c9..d94cabcb 100644
--- a/python/pykde/doc/limits.html
+++ b/python/pykde/doc/limits.html
@@ -79,18 +79,18 @@ NAME="AEN30"
 >Unicode support was added to Qt in v2.0 and to Python in v1.6.  In Qt, Unicode
 support is implemented using the <TT
 CLASS="LITERAL"
->QString</TT
+>TQString</TT
 > class.  It is
 important to understand that <TT
 CLASS="LITERAL"
->QString</TT
+>TQString</TT
 >s, Python string objects
 and Python Unicode objects are all different but conversions between them are
 automatic in many cases and easy to achieve manually when needed.</P
 ><P
 >Whenever PyKDE expects a <TT
 CLASS="LITERAL"
->QString</TT
+>TQString</TT
 > as a function argument, a
 Python string object or a Python Unicode object can be provided instead, and
 PyKDE will do the necessary conversion automatically.</P
@@ -98,10 +98,10 @@ PyKDE will do the necessary conversion automatically.</P
 >You may also manually convert Python string and Unicode objects to
 <TT
 CLASS="LITERAL"
->QString</TT
+>TQString</TT
 >s by using the <TT
 CLASS="LITERAL"
->QString</TT
+>TQString</TT
 > constructor
 as demonstrated in the following code fragment.</P
 ><TABLE
@@ -112,15 +112,15 @@ WIDTH="100%"
 ><TD
 ><PRE
 CLASS="PROGRAMLISTING"
->qs1 = QString('Converted Python string object')
-qs2 = QString(u'Converted Python Unicode object')</PRE
+>qs1 = TQString('Converted Python string object')
+qs2 = TQString(u'Converted Python Unicode object')</PRE
 ></TD
 ></TR
 ></TABLE
 ><P
 >In order to convert a <TT
 CLASS="LITERAL"
->QString</TT
+>TQString</TT
 > to a Python string object use
 the Python <TT
 CLASS="LITERAL"
@@ -131,16 +131,16 @@ CLASS="LITERAL"
 >str()</TT
 > to a null <TT
 CLASS="LITERAL"
->QString</TT
+>TQString</TT
 > and an empty
 <TT
 CLASS="LITERAL"
->QString</TT
+>TQString</TT
 > both result in an empty Python string object.</P
 ><P
 >In order to convert a <TT
 CLASS="LITERAL"
->QString</TT
+>TQString</TT
 > to a Python Unicode object use
 the Python <TT
 CLASS="LITERAL"
@@ -151,11 +151,11 @@ CLASS="LITERAL"
 >unicode()</TT
 > to a null <TT
 CLASS="LITERAL"
->QString</TT
+>TQString</TT
 > and an empty
 <TT
 CLASS="LITERAL"
->QString</TT
+>TQString</TT
 > both result in an empty Python Unicode object.</P
 ></DIV
 ><DIV
@@ -193,8 +193,8 @@ WIDTH="100%"
 ><TD
 ><PRE
 CLASS="PROGRAMLISTING"
->c = QColor();
-c = QColor();</PRE
+>c = TQColor();
+c = TQColor();</PRE
 ></TD
 ></TR
 ></TABLE
@@ -212,8 +212,8 @@ WIDTH="100%"
 ><TD
 ><PRE
 CLASS="PROGRAMLISTING"
->c = QColor()
-c = QColor()</PRE
+>c = TQColor()
+c = TQColor()</PRE
 ></TD
 ></TR
 ></TABLE
@@ -228,8 +228,8 @@ WIDTH="100%"
 ><TD
 ><PRE
 CLASS="PROGRAMLISTING"
->self.c1 = QColor()
-self.c2 = QColor()</PRE
+>self.c1 = TQColor()
+self.c2 = TQColor()</PRE
 ></TD
 ></TR
 ></TABLE
@@ -238,7 +238,7 @@ self.c2 = QColor()</PRE
 will eventually call the destructor of that second instance. The most common
 example is that a <TT
 CLASS="LITERAL"
->QObject</TT
+>TQObject</TT
 > (and any of its sub-classes) keeps
 pointers to its children and will automatically call their destructors. In
 these cases, the corresponding Python object will also keep a reference to the
@@ -246,7 +246,7 @@ corresponding child objects.</P
 ><P
 >So, in the following Python fragment, the first <TT
 CLASS="LITERAL"
->QLabel</TT
+>TQLabel</TT
 > is
 not destroyed when the second is assigned to <TT
 CLASS="LITERAL"
@@ -254,7 +254,7 @@ CLASS="LITERAL"
 > because the
 parent <TT
 CLASS="LITERAL"
->QWidget</TT
+>TQWidget</TT
 > still has a reference to it.</P
 ><TABLE
 BORDER="0"
@@ -264,9 +264,9 @@ WIDTH="100%"
 ><TD
 ><PRE
 CLASS="PROGRAMLISTING"
->p = QWidget()
-l = QLabel('First label',p)
-l = QLabel('Second label',p)</PRE
+>p = TQWidget()
+l = TQLabel('First label',p)
+l = TQLabel('Second label',p)</PRE
 ></TD
 ></TR
 ></TABLE
@@ -290,9 +290,9 @@ WIDTH="100%"
 ><TD
 ><PRE
 CLASS="PROGRAMLISTING"
->tab = QTab()
+>tab = TQTab()
 tab.label = "First Tab"
-tab.r = QRect(10,10,75,30)</PRE
+tab.r = TQRect(10,10,75,30)</PRE
 ></TD
 ></TR
 ></TABLE
@@ -320,8 +320,8 @@ one Qt class.</P
 
 <H2 CLASS="SECT2">tr() methods</H2>
 <P>
-In a normal Qt installation, every descendant of QObject inherits two methods
-(tr (const char *) and tr (const char *, const char *) from QObject explicitly
+In a normal Qt installation, every descendant of TQObject inherits two methods
+(tr (const char *) and tr (const char *, const char *) from TQObject explicitly
 and also overloads these methods via the moc mechanism (by defining Q_OBJECT
 in the class declaration). KDE however is compiled with -DQT_NO_TRANSLATION,
 which prevents moc from creating the overloading tr() methods, and also produces
@@ -330,9 +330,9 @@ side-effects with a normal Qt installation which was compiled without the
 </P>
 <P>
 PyKDE handles this situation by NOT providing tr() methods (either the inherited
-methods from QObject or the moc generated methods) for any KDE based QObject
-descendant. The tr() methods are static, so QObject::tr () methods are available
-via PyQt, as are tr() methods for any PyQt QObject descendant. PyKDE's handling
+methods from TQObject or the moc generated methods) for any KDE based QObject
+descendant. The tr() methods are static, so TQObject::tr () methods are available
+via PyQt, as are tr() methods for any PyQt TQObject descendant. PyKDE's handling
 of these methods has no effect on PyQt.
 </P>
 <P>Instead of the tr() methods, KDE uses corresponding i18n() methods for translating.