|author||tpearson <tpearson@283d02a7-25f6-0310-bc7c-ecb5cbfe19da>||2011-08-10 22:19:39 +0000|
|committer||tpearson <tpearson@283d02a7-25f6-0310-bc7c-ecb5cbfe19da>||2011-08-10 22:19:39 +0000|
rename the following methods:
tqparent parent tqmask mask git-svn-id: svn://anonsvn.kde.org/home/kde/branches/trinity/kdepim@1246260 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
Diffstat (limited to 'kmail/Mainpage.dox')
1 files changed, 22 insertions, 22 deletions
diff --git a/kmail/Mainpage.dox b/kmail/Mainpage.dox
index ab239109..cc111158 100644
@@ -527,7 +527,7 @@ class SortCacheItem:
folder) messages is cached on disk in a file named .$FOLDER.index.sorted
so if, for example the name of a folder is foo, the associated sorting
cache file would be called ".foo.index.sorted".
- For each message, its serial number, that of its tqparent, the length of its
+ For each message, its serial number, that of its parent, the length of its
sorting key, and the key itself are written to this file. At the start of
the file several per folder counts and flags are cached additionally,
immediately after a short file headers. The entries from the start of the
@@ -544,13 +544,13 @@ class SortCacheItem:
What is used for figuring out threading?
- messages can have an In-Reply-To header that contains the message id of
- another message. This is called a perfect tqparent.
+ another message. This is called a perfect parent.
- additionally there is the References header which, if present, holds a
list of message ids that the current message is a follow up to. We
currently use the second to last entry in that list only. See further
down for the reasoning behind that.
- If the above two fail and the message is prefixed (Re: foo, Fwd: foo etc.)
- an attempt is made to find a tqparent by looking for messages with the same
+ an attempt is made to find a parent by looking for messages with the same
subject. How that is done is explained below as well.
For all these comparisons of header contents, the md5 hashes of the headers
@@ -578,22 +578,22 @@ Strategy:
has been moved away in the meantime (possibly by outside forces such as
other clients) and a deleted counter is incremented and all further
processing stopped for this message.
- The messages tqparent serial number, as read from the sorted file is then
- used to look up the tqparent and reset it to -1 should it not be in the
+ The messages parent serial number, as read from the sorted file is then
+ used to look up the parent and reset it to -1 should it not be in the
current folder anymore. -1 and -2 are special values that can show up
- as tqparent serial numbers and are used to encode the following:
- -1 means this message has no perfect tqparent, a tqparent for it needs to
+ as parent serial numbers and are used to encode the following:
+ -1 means this message has no perfect parent, a parent for it needs to
be found from among the other messages, if there is a suitable one
-2 means this message is top level and will forever stay so, no need
- to even try to find a tqparent. This is also used for the non-threaded
+ to even try to find a parent. This is also used for the non-threaded
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 tqparent, the current sort cache item is
+ 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
root, if there is not. A sort cache item is created in the mSortCache
- for the tqparent, if it is not already there. Messages with a tqparent of
+ 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 tqparent are tqchildren of
+ its elements threaded. Messages with -2 as the parent are tqchildren 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
@@ -612,7 +612,7 @@ Strategy:
The next step is finding parents for those messages that are either new, or
- had a tqparent of -1 in the .sorted file. To that end, a dict of all sort
+ had a parent of -1 in the .sorted file. To that end, a dict of all sort
cache items indexed by the md5 hash of their messsage id headers is created,
that will be used for looking up sort cache items by message id. The list of
yet unparented messages is then traversed and findParent() called for each
@@ -638,7 +638,7 @@ Strategy:
- since the above is a common special case, it is worth trying. I think. ;)
- If the tqparent found is perfect (In-Reply-To), the sort cache items is marked
+ If the parent found is perfect (In-Reply-To), the sort cache items is marked
as such. mIsImperfectlyThreaded is used for that purposer, we will soon see
why that flag is needed.
@@ -647,29 +647,29 @@ Strategy:
are collected into a second dict ( QDict< QPtrList< SortCacheItem > > )
that contains for each different subject an entry holding a list of (so far
top level) messages with that subject, that are potential parents for
- threading by subjects. These lists are sorted by date, so the tqparent closest
+ threading by subjects. These lists are sorted by date, so the parent closest
by date can be chosen. Sorting of these lists happens via insertion sort
while they are built because not only are they expected to be short (apart
from hard corner cases such as cvs commit lists, for which subject threading
makes little sense anyhow and where it should be turned off), but also since
the messages should be roughly pre sorted by date in the store already.
Some cursory benchmarking supports that assumption.
- If now a tqparent is needed for a message with a certain subject, the list of
+ If now a parent is needed for a message with a certain subject, the list of
top level messages with that subject is traversed and the first one that is
- older than our message is chosen as it's tqparent. Parents more than six weeks
+ older than our message is chosen as it's parent. Parents more than six weeks
older than the message are not accepted. The reasoning being that if a new
message with the same subject turns up after such a long time, the chances
that it is still part of the same thread are slim. The value of six weeks
is chosen as a result of a poll conducted on #kde-devel, so it's probably
bogus. :) All of this happens in the aptly named: findParentBySubject().
- Everthing that still has no tqparent after this ends up at toplevel, no further
+ Everthing that still has no parent after this ends up at toplevel, no further
attemp is made at finding one. If you are reading this because you want to
implement threading by body search or somesuch, please go away, I don't like
Ok, so far we have only operated on sort cache items, nothing ui wise has
- happened yet. Now that we have established the tqparent/child relations of all
+ happened yet. Now that we have established the parent/child relations of all
messages, it's time to create HeaderItems for them for use in the header
list. But wait, you say, what about sorting? Wouldn't it make sense to do
that first? Exactly, you're a clever bugger, ey? Here, have a cookie. ;)
@@ -706,14 +706,14 @@ What happens when a message arrives in the folder?
structures described above are updated accordingly. If threading is enabled,
the new message is threaded using the same findParent and findParentBySubject
methods used on folder open. If the message ends up in a watched or ignored
- thread, those status bits are inherited from the tqparent. The message is also
+ thread, those status bits are inherited from the parent. The message is also
added to the dict of header items, the index of messages by message id and,
if applicable and if the message is threaded at top level, to the list of
potential parents for subject threading.
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 tqparent for each item on it. This is especially important
+ 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
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
@@ -735,7 +735,7 @@ What happens when a message is removed from the folder?
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
- root at top level, because there is no need to find a tqparent for it if it is
+ 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
whole thread. The KMMoveCommand marks all messages that will be moved out of
@@ -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
- That list of tqchildren is then traversed and a new tqparent found for each one
+ That list of tqchildren 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.