Replace QObject, QWidget, QImage, QPair, QRgb, QColor, QChar, QString, QIODevice with TQ* version

Signed-off-by: Michele Calgaro <michele.calgaro@yahoo.it>

1 files changed, 8 insertions, 8 deletions

diff --git a/kmail/Mainpage.dox b/kmail/Mainpage.dox
index 3121e2d97..cd21bf042 100644
--- a/kmail/Mainpage.dox
+++ b/kmail/Mainpage.dox
@@ -109,8 +109,8 @@ instance of the filter manager is held by the kernel
 The search pattern is a QPtrList of search rules (kmsearchpattern.h) and a
 boolean operator that defines their relation (and/or).
 
-A search rule consists of a field-QString, a "function"-enum and a
-"contents" or "value" QString. The first gives the header (or
+A search rule consists of a field-TQString, a "function"-enum and a
+"contents" or "value" TQString. The first gives the header (or
 pseudoheader) to match against, the second says how to match (equals,
 consists, is less than,...) and the third holds the pattern to match
 against.
@@ -155,7 +155,7 @@ the corresponding config manager instead. But that won't change the
 basic principle.
 
 Thus, there is an abstract base class ConfigurePage (defined in
-configuredialog_p.h), which derives from QWidget. It has four methods
+configuredialog_p.h), which derives from TQWidget. It has four methods
 of which you have to reimplement at least the first two:
 
 - void setup()
@@ -239,7 +239,7 @@ as follows :
         ---< actual folder types: KMFolderImap, KMFolderMbox... >--
 
 At the base KMail's folder design starts with KMFolderNode which
-inherits QObject. KMFolderNode is the base class encapsulating
+inherits TQObject. KMFolderNode is the base class encapsulating
 common folder properties such as the name and a boolean signifying whether
 the folder is a folder holding mail directly or a KMFolderDir.
 KMFolderNode's often do not have an on-disk representation, they are
@@ -410,7 +410,7 @@ uniq: 3 bits = max. 8 different types with same chunk size:
 	010 Offset32
         011 SerNum/UOID
 	100 DateTime
-	101 Color (QRgb: (a,r,g,b))
+	101 Color (TQRgb: (a,r,g,b))
 	110 reserved
 	111 Extend
 
@@ -821,7 +821,7 @@ During the design phase we identified a need for BodyPartFormatters to
 request their being called on some form of events, e.g. a dcop
 signal. Thus, the Memento interface also includes the IObserver and
 ISubject interfaces. If a BodyPartFormatter needs to react to a signal
-(Qt or DCOP), it implements the Memento interface using a QObject,
+(Qt or DCOP), it implements the Memento interface using a TQObject,
 connects the signal to a slot on the Memento and (as an ISubject)
 notifies it's IObservers when the slot is called. If a Memento is
 created, the reader window registers itself as an observer of the
@@ -850,10 +850,10 @@ public:
 };
 
 class DelayedHelloWorldBodyPartMemento
-      : public QObject, public KMail::BodyPartMemento {
+      : public TQObject, public KMail::BodyPartMemento {
 public:
   DelayedHelloWorldBodyPartMemento()
-    : QObject( 0, "DelayedHelloWorldBodyPartMemento" ),
+    : TQObject( 0, "DelayedHelloWorldBodyPartMemento" ),
       KMail::BodyPartMemento()
   {
     QTimer::singleShot( 10*1000, this, SLOT(slotTimeout()) );