summaryrefslogtreecommitdiffstats
path: root/kmail/Mainpage.dox
diff options
context:
space:
mode:
authorTimothy Pearson <kb9vqf@pearsoncomputing.net>2011-12-19 11:59:01 -0600
committerTimothy Pearson <kb9vqf@pearsoncomputing.net>2011-12-19 11:59:01 -0600
commit716a5de8870d7c02bb4d0aed72f30291b17b763a (patch)
tree29e58b213ead28151ccf7eb33d12c968ea844120 /kmail/Mainpage.dox
parent0e00c0a86a4c9d7e80c7b66d91940cc7dcb79f78 (diff)
downloadtdepim-716a5de8870d7c02bb4d0aed72f30291b17b763a.tar.gz
tdepim-716a5de8870d7c02bb4d0aed72f30291b17b763a.zip
Remove additional unneeded tq method conversions
Diffstat (limited to 'kmail/Mainpage.dox')
-rw-r--r--kmail/Mainpage.dox20
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.