diff options
Diffstat (limited to 'kmail/Mainpage.dox')
| -rw-r--r-- | kmail/Mainpage.dox | 44 |
1 files changed, 22 insertions, 22 deletions
diff --git a/kmail/Mainpage.dox b/kmail/Mainpage.dox index ab2391090..cc1111582 100644 --- a/kmail/Mainpage.dox +++ b/kmail/Mainpage.dox @@ -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: well. 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 you. :) 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 action. - 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. |