diff options
Diffstat (limited to 'kmail/Mainpage.dox')
| -rw-r--r-- | kmail/Mainpage.dox | 34 |
1 files changed, 17 insertions, 17 deletions
diff --git a/kmail/Mainpage.dox b/kmail/Mainpage.dox index d970bbe8a..9c24f4598 100644 --- a/kmail/Mainpage.dox +++ b/kmail/Mainpage.dox @@ -316,9 +316,9 @@ with questions... length := Q_UINT16 ; little endian (native?) - value := unicode-string-value / ulong-value + value := tqunicode-string-value / ulong-value - unicode-string-value := 0*256QChar ; network-byte-order + tqunicode-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!) - LegacyStatus 8 l mLegacyStatus + LegacytqStatus 8 l mLegacytqStatus 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() - Status 16 l status() + tqStatus 16 l status() - u: unicode-string-value; l: ulong-value + u: tqunicode-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_) - Status BitField (see below) + tqStatus 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 Status BitField are: +Currently allocated bits for the tqStatus 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 children, or to that of + 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 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 children 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 @@ -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 children. Starting with the root node the + sorted and one of its unsorted tqchildren. Starting with the root node the unsorted list is first qsorted, and then merged with the list of already - sorted children. To achieve that, the heads of both lists are compared and + sorted tqchildren. 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 - children, it is added to the end of a queue of nodes to repeat these steps + tqchildren, 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 children still end + 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 .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 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 + 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 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 children is then traversed and a new parent 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. |