Remove additional unneeded tq method conversions

1 files changed, 10 insertions, 10 deletions

diff --git a/kmail/Mainpage.dox b/kmail/Mainpage.dox
index 05802ef7c..cdab18acb 100644
--- a/kmail/Mainpage.dox
+++ b/kmail/Mainpage.dox
@@ -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.