summaryrefslogtreecommitdiffstats
path: root/kmail/Mainpage.dox
diff options
context:
space:
mode:
Diffstat (limited to 'kmail/Mainpage.dox')
-rw-r--r--kmail/Mainpage.dox16
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()) );