diff options
Diffstat (limited to 'kmail/Mainpage.dox')
| -rw-r--r-- | kmail/Mainpage.dox | 104 |
1 files changed, 52 insertions, 52 deletions
diff --git a/kmail/Mainpage.dox b/kmail/Mainpage.dox index 0b15ebfb..8f7a6503 100644 --- a/kmail/Mainpage.dox +++ b/kmail/Mainpage.dox @@ -71,7 +71,7 @@ is not modal and the user may hit apply/ok anytime between calls to function that want to use the identity reference. Store the UOID instead if you need to keep track of the identity. You may also want to connect to one of the KPIM::IdentityManager::changed() or ::deleted() -signals, if you want to do special processing in case the identity +Q_SIGNALS, if you want to do special processing in case the identity changes. Thus, in the ConfigureDialog, you will see non-const KPIM::Identity @@ -271,13 +271,13 @@ accessed via KMKernel ( the "kmkernel" construct ). Those methods are : folder manager. In dimap, both the headers and a copy of the full message are cached locally. 4) KMFolderMgr *searchFolderMgr() - which returns the folder manager - for search folders (folders created by using the "find + for search folders (folders created by using the "tqfind messages" tool). Other email clients call this type of folder "virtual folders". FolderJob classes - These classes allow asynchronous operations on KMFolder's. You create a Job on the heap, connect to one of its -signals and wait for the job to finish. Folders serve as FolderJob +Q_SIGNALS and wait for the job to finish. Folders serve as FolderJob factories. For example, to retrieve the full message from a folder you do : @@ -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,20 +446,20 @@ 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 ThreadHeads SerialNumberList MD5Hash's of all (so far discovered) - _top-level thread parents_ + _top-level thread tqparents_ ThreadParents SerialNumberList MD5Hash's of all (so far discovered) - thread parents + thread tqparents "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) @@ -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 parent, the length of its + For each message, its serial number, that of its tqparent, 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 parent. + another message. This is called a perfect tqparent. - 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 parent by looking for messages with the same + an attempt is made to find a tqparent 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,27 +578,27 @@ 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 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 + 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 current folder anymore. -1 and -2 are special values that can show up - 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 + 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 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 parent. This is also used for the non-threaded + to even try to find a tqparent. 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 parent, the current sort cache item is - appended to the parents list of unsorted children, or to that of + In case there is a perfect tqparent, the current sort cache item is + appended to the tqparents 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 + for the tqparent, if it is not already there. Messages with a tqparent of + -1 are appended to the "untqparented" list, which is later traversed and + its elements threaded. Messages with -2 as the tqparent 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 mSortCache, containing a sort cache item for each message that was in the - sorted file. Messages with perfect parents know about them, top level + sorted file. Messages with perfect tqparents know about them, top level messages know about that as well, all others are on a list and will be threaded later. @@ -608,16 +608,16 @@ Strategy: to mFolder->count() are looked at and a SortCacheItem is created for the ones that do not have one yet. This is where all sort cache items are created if there was no sorted file. The items created here are by definition un- - sorted as well as unparented. On creation their sort key is figured out as + sorted as well as untqparented. On creation their sort key is figured out as well. - The next step is finding parents for those messages that are either new, or - had a parent of -1 in the .sorted file. To that end, a dict of all sort + The next step is finding tqparents 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 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 + yet untqparented messages is then traversed and findParent() called for each element wihch checks In-Reply-To and References headers and looks up the - sort cache item of those parents in the above mentioned dict. Should none be + sort cache item of those tqparents in the above mentioned dict. Should none be found, the item is added to a second list the items of which will be subject threaded. @@ -638,7 +638,7 @@ Strategy: - since the above is a common special case, it is worth trying. I think. ;) - If the parent found is perfect (In-Reply-To), the sort cache items is marked + If the tqparent 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. @@ -646,30 +646,30 @@ Strategy: the messages that are now top-level, the current thread heads, so to speak, 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 parent closest + top level) messages with that subject, that are potential tqparents for + threading by subjects. These lists are sorted by date, so the tqparent 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 parent is needed for a message with a certain subject, the list of + If now a tqparent 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 parent. Parents more than six weeks + older than our message is chosen as it's tqparent. 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 parent after this ends up at toplevel, no further + Everthing that still has no tqparent 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 parent/child relations of all + happened yet. Now that we have established the tqparent/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. ;) @@ -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. @@ -706,16 +706,16 @@ 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 parent. The message is also + thread, those status bits are inherited from the tqparent. 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. + potential tqparents 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 parent for each item on it. This is especially important - 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 + considered as a new tqparent for each item on it. This is especially important + to ensure that tqparents arriving out of order after their tqchildren still end + up as tqparents. 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,10 +732,10 @@ 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 - root at top level, because there is no need to find a parent for it if it is + 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 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 children is then traversed and a new parent found for each one + That list of tqchildren is then traversed and a new tqparent 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. @@ -859,7 +859,7 @@ public: QTimer::singleShot( 10*1000, this, SLOT(slotTimeout()) ); } -private slots: +private Q_SLOTS: void slotTimeout() { notify(): } private: |