Rename a number of old tq methods that are no longer tq specific

1 files changed, 17 insertions, 17 deletions

diff --git a/kmail/Mainpage.dox b/kmail/Mainpage.dox
index 9c24f4598..d970bbe8a 100644
--- a/kmail/Mainpage.dox
+++ b/kmail/Mainpage.dox
@@ -316,9 +316,9 @@ with questions...
 
    length := Q_UINT16 ; little endian (native?)
 
-   value := tqunicode-string-value / ulong-value
+   value := unicode-string-value / ulong-value
 
-   tqunicode-string-value := 0*256QChar ; network-byte-order
+   unicode-string-value := 0*256QChar ; network-byte-order
 
    ulong-value := unsigned_long ; little endian
 
@@ -334,7 +334,7 @@ Currently defined tag values are:
    IdMD5	 5	   u	msgIdMD5().stripWhiteSpace()
    XMark	 6	   u	xmark().stripWhiteSpace()
    Offset	 7	   l	folderOffset() (not only mbox!)
-   LegacytqStatus	 8	   l	mLegacytqStatus
+   LegacyStatus	 8	   l	mLegacyStatus
    Size		 9	   l	msgSize()
    Date		 10	   l	date()
    File		 11	   u	fileName() (not only maildir!)
@@ -342,9 +342,9 @@ Currently defined tag values are:
    MDNSent	 13	   l	mdnSentState()
    ReplyToAuxIdMD5 14	   u	replyToAuxIdMD5()
    StrippedSubject 15	   u	strippedSubjectMD5().stripWhiteSpace()
-   tqStatus	   16	   l	status()
+   Status	   16	   l	status()
 
-   u: tqunicode-string-value; l: ulong-value
+   u: unicode-string-value; l: ulong-value
 
 Proposed new (KDE 3.2 / KMail 1.6) entry format:
 
@@ -446,7 +446,7 @@ Currently defined tags are:
    MBoxOffset	     Offset(64) Offset in mbox file (pointing to From_)
    MBoxLength        Size(64)   Length of message in mbox file (incl. From_)
    Size		     Size(64)	rfc2822-size of message (in mbox: excl. From_)
-   tqStatus	     BitField	(see below)
+   Status	     BitField	(see below)
    MessageIdMD5	     MD5Hash	MD5Hash of _normalized_ Message-Id:
    MDNLink	     SerialNumber SerNum of MDN received for this message
    DNSLink	     SerialNumber SerNUm of DSN received for this message
@@ -459,7 +459,7 @@ Currently defined tags are:
    "String" is either Utf8String or (Utf16String or Latin1String),
 	    depending on content
 
-Currently allocated bits for the tqStatus BitField are:
+Currently allocated bits for the Status BitField are:
 
     Bit              Value: on(/off) (\\imapflag)
 
@@ -589,11 +589,11 @@ Strategy:
   case. These are messages that have neither an In-Reply-To header nor
   a References header and have a subject that is not prefixed.
   In case there is a perfect parent, the current sort cache item is
-  appended to the parents list of unsorted tqchildren, or to that of
+  appended to the parents list of unsorted children, or to that of
   root, if there is not. A sort cache item is created in the mSortCache
   for the parent, if it is not already there. Messages with a parent of
   -1 are appended to the "unparented" list, which is later traversed and
-  its elements threaded. Messages with -2 as the parent are tqchildren of
+  its elements threaded. Messages with -2 as the parent are children of
   root as well, as noted above, and will remain so. 
 
   Once the end of the file is reached, we should have a nicely filled 
@@ -677,13 +677,13 @@ Strategy:
   cache items happen at the same time. 
   
   As previously mentioned (or not) each sort cache item holds a list of its
-  sorted and one of its unsorted tqchildren. Starting with the root node the
+  sorted and one of its unsorted children. Starting with the root node the
   unsorted list is first qsorted, and then merged with the list of already
-  sorted tqchildren. To achieve that, the heads of both lists are compared and
+  sorted children. To achieve that, the heads of both lists are compared and
   the one with the "better" key is added to the list view next by creating a
   KMHeaderListItem for it. That header item receives both its sort key as well
   as its id from the sort cache item. Should the current sort cache item have
-  tqchildren, it is added to the end of a queue of nodes to repeat these steps
+  children, it is added to the end of a queue of nodes to repeat these steps
   on after the current level is sorted. This way, a breadth first merge sort
   is performed on the sort cache items and header items are created at each
   node.
@@ -714,7 +714,7 @@ What happens when a message arrives in the folder?
   After those house keeping tasks are performed, the list of as of yet imper-
   fectly threaded messages is traversed and our newly arrived message is 
   considered as a new parent for each item on it. This is especially important
-  to ensure that parents arriving out of order after their tqchildren still end
+  to ensure that parents arriving out of order after their children still end
   up as parents. If necessary, the entries in the .sorted file of rethreaded
   messages are updated. An entry for the new message itself is appended to the
   .sorted file as well.
@@ -732,9 +732,9 @@ What happens when a message is removed from the folder?
   In this case the msgRemoved slot kicks in and updates the headers list. First
   the sort cache item and header item representing our message are removed from
   the data structures and the ids of all items after it in the store decre-
-  mented. Then a list of tqchildren of the message is assembled containing those
-  tqchildren that have to be reparented now that our message has gone away. If 
-  one of those tqchildren has been marked as toBeDeleted, it is simply added to 
+  mented. Then a list of children of the message is assembled containing those
+  children that have to be reparented now that our message has gone away. If 
+  one of those children has been marked as toBeDeleted, it is simply added to 
   root at top level, because there is no need to find a parent for it if it is
   to go away as well. This is an optimization to avoid rethreading  all 
   messages in a thread when deleting several messages in a thread, or even the
@@ -743,7 +743,7 @@ What happens when a message is removed from the folder?
   can be avoided. Note that that does not work when moving messages via filter
   action. 
 
-  That list of tqchildren is then traversed and a new parent found for each one
+  That list of children is then traversed and a new parent found for each one
   using, again, findParent and findParentBySubject. When a message becomes
   imperfectly threaded in the process, it is added to the corresponding list.