[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    TODO List
From:       Don Sanders <dsanders () cch ! com ! au>
Date:       2000-03-20 20:43:56
[Download RAW message or body]

I felt like posting a todo list. Here's what I would like to see implemented 
by the next release of KMail. Any additions?

Bugs
 Certain folders are compacting when it is not necessary
 Send mail dialog shows overlapping text.
 Reply all, reply doing weird stuff, eg showing duplicate entries.
 KMMsgBase skipkeyword algorithm is screwed just skips stuff in front of ':'.
  Should skip ( "Fwd: ", "Re: ", "FWD: ", "RE: " )+
 Segfault on exit due to kparts bug (also long/short folder list) (QT bug)
  Number of unread messages is getting messed up (maybe because of above seg?)
 Spell checking, afterwards document is readonly!
 POP3 kioslave is broken
 DnD from kfm not woring
 Various html widget bugs
 EOL Key right completion, should be changed to Ctrl-Right completion I think
 Subtle refresh problem in KMFolderTree

Features
 Colorfied indenting
 New settings dialog
 Multiple accounts 
   (with customizable signatures, send mail config, and email address).
 Search Dialog
 New addressbook
 Index file needs reply to and this id
  (Threading maybe not hard to do but maybe hard to get just right)
 Update about dialog
 Backing pixmaps (waiting for QT)
 (Non blocking sending of mail, not in the near future)
 (IMAP unrealistic in near future)

Bugs Done
 In folder tree If move mouse and mouse button down and not in DnD operation
  ignore.
 KMComposeWin attaching files is sometimes failing.
 Address book bug
 Memory leak
 C/M copy/move dialogs need to be disabled or updated.

Memory leaks.

I spent some time looking into the KMail 'memory leak' problem. I looked into 
this a while ago and concluded that KMail was guilty of excessive memory 
pooling rather than memory leaking, and that a resize(?) call somewhere in 
kmfolder(?) was the culprit. I came to this conclusion after using the 
Electric Fence memory debugger and not finding any significant memory leaks.

I looked into this some more. I still think KMail is guilty of excessive 
memory pooling rather than memory leaking but I was wrong to think it had 
anything to do with a call to resize, (I think I confused realloc and 
resize). Instead it just seems to be due to the fact that every time a user 
selects a message header memory is allocated for the body of that message, 
and that memory isn't freed until the user selects a different folder.

I noticed even after I read a whole lot of messags and change to a different 
folder the amount of memory (SIZE, RSS) used by KMail as shown by top doesn't 
decrease. Given that memory really is being freed when the user changes to a 
different folder this is somewhat bogus, but I guess it's just because top is 
showing the size of the heap, which doesn't necessarily shrink when memory is 
freed, (maybe it never shrinks when using gcc to compile C++ programs?).

Anyway I conclude if we want to limit the amount of memory used by KMail then 
we need to implement some kind of queue for the mesage list class KMMsgList, 
so that least recently used messages are freed. I not too interested in doing 
this at the moment.

BFN,
Don.

[prev in list] [next in list] [prev in thread] [next in thread]