diff options
Diffstat (limited to 'kmail')
| -rw-r--r-- | kmail/Mainpage.dox | 16 |
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()) ); |