For these messages the additional server roundtrips slow things down. Nice side effect: the msg size is displayed correctly
in the mimetree. Messages that are already in your folder will be loaded with lod the first time because the size is unknown.
After that (and for all new messages) this should work as expected.
Happy New Year :-)
svn path=/trunk/kdepim/; revision=275786
full server roundtrip for each mail but processing them in chunks according
to their target set of flags. This is especially noticeable with "mark all
as read" on a large folder. That goes from minutes to seconds.
svn path=/trunk/kdepim/; revision=275461
in any slave job data maps of the account. This is especially problematic
during mailchecks, as those then never complete and cancelling them leads
to crashes. Also make sure account state is reset so further mailchecks
etc are possible.
Zack, Carsten, there is an ambiguity in naming here, what with kio jobs and
folder jobs. Any ideas how to improve that?
svn path=/trunk/kdepim/; revision=273247
- when you clicked the first time on a msg the signaturestate was unknown and the msg was loaded completely
so I include the unknown state
- the temporary files from attachments are readonly because of a bugfix - this is bad because we need to replace them
so I set the file to writeable, replace it and set it back to readonly
and - it is magic - the download of attachments works again :-)
svn path=/trunk/kdepim/; revision=270715
active readerwindow to ask that for the attachmentstrategy but pass it
along with the folder job, so it is available when the mime structure
comes in with load on demand. Remove unused KMKernel::activeReaderWindow
which doesn't work in kontact anyhow.
CCMAIL: 67644-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=268877
newly arrived mail headers will be added to the local store but the headers
list not updated as that happens according to the following scheme:
o set folder quiet++
o get a bunch of headers and add them to the store without updating
o when the last mail comes in set folder quiet--
o quiet == 0 and as a result of that emit the folder's changed signal which
updates the headers
Now if in some error path the quiet-- doesn't happen, quiet never
becomes 0 again in that folder and therefor the headers are never updated
whether there are new mails or not.
I hope this is the last codepath where it is lacking. If so, it should
fix#64210. This being an error path would explain why it is so elusive. I
saw this today for the first time having left kmail running across a
disconnect of my internet connection.
CCMAIL: 64210@bugs.kde.org
svn path=/trunk/kdepim/; revision=267320
folder in the foldertree is removed and guard against crashing when the
non existing folder is mailchecked before it can be removed.
CCMAIL: 65954-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=265481
folders, adding the messages one by one to the header listview is very
slow. With pop, where each body is downloaded anyhow which takes a lot
longer, that is not a factor, but with imap this results in a massive
slowdown. Get all of them and then redraw the listview completely, as
before.
I'm planning to hunt down why this is so slow after 3.2, as this is just
working around the real problem.
svn path=/trunk/kdepim/; revision=261394
signals from being emitted.
This should fix the sent folder count updating bug. If it does not for
you, please reopen.
Patch Ok'ed by Till (Don also agreed that quiet() can be removed).
CCMAIL: 63670-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=260199
folders somewhat brutally by making sure that the following does not
happen:
- KMFolderImap::removeMsg(QPtrList<KMMessage>) tells the imap server to
mark a range of messages as deleted, say 1024:1203
- KMFolderImapInherited::removeMsg(QPtrList<KMMessage>) is called to make
sure the message are removed from the local store
- that one calls removeMsg(int message) which is turns out to be
KMFolderImap::removeMsg(int), which tells the imap server to mark _one_
message as deleted ... for each of the list of messages
This hardcodes KMFolderMbox::removeMsg(int) in KMFolderImap::removeMsg()
which is not so nice, but hey.
svn path=/trunk/kdepim/; revision=256571
crashes due to stuff operating on the disappeared inbox, presumably. I'm
not sure if this was a typo, since the .upper() part of the change seems
sensible, so I leave that part of the commit in. Carsten?
svn path=/trunk/kdepim/; revision=256547
account associated with it yet. This can happen when you create a new imap
folder and then click on it before the server has finished acknowledging
its existance.
svn path=/trunk/kdepim/; revision=254002
command up to the target folder's msgAdded signals and ticking off each
serial number as it comes in. To make that possible, use the metaDataMap
for imap folders to restore serial numbers after the move (along with
status). Also connect to the folderCompleted(bool) signal of imap folders
to make sure we notice if not all messages make it to the other side.
Connect kmheaders to the abortRequested signal and make sure cancelling
moves behaves somewhat more gracefully and restores the state of messages
remaining in the folder, making them selectable and setting their transfer
status to false so they can be downloaded or moved again.
svn path=/trunk/kdepim/; revision=252676
#define kernel KMKernel::self()
to
#define kmkernel KMKernel::self()
because 'kernel' was a much to general term. We really shouldn't repeat the mistakes of the X developers.
I noticed this problem when I played around with KImageEffects. kimageeffects.h contains 'kernel' as parameter of some methods and so the compilation had to fail. We won't need KImageEffects in the near future, but at least we are now prepared and a clash with another 'kernel' can't happen anymore.
svn path=/trunk/kdepim/; revision=252621
list as before or to the right of it or hide it completely. When the reader
window is disabled, messages that are selected are not downloaded (for
imap) and are not marked as read.
CCMAIL: 63647-done@bugs.kde.org
CCMAIL: 16345-done@bugs.kde.org
CCMAIL: 43176-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=249504
(I still have to do this for the direct click on the attachment)
- fix saving of one attachment (filename was not displayed because the mimeheader was missing)
save all attachments works as expected but doesn't update the parts in the readerwin, I still need to fix this
svn path=/trunk/kdepim/; revision=249206
opening and closing on each folder tree mail count update by actually
reading the unread and total counts from the config file. How, you ask, is
such magic possible? By calling the inherited KMFolder::readConfig() from
KMFolderImap::readConfig(). No telling what else this fixes ...
svn path=/trunk/kdepim/; revision=248873
o make imapjobs refcount the folders they operate on via open/close instead
of relying on the account to keep track of open folders and close them
in displayProgress()
o keep not only the destination but also the source folder in each imapjob
so they can be closed if need be
o remove tempOpenFolder() itself and all its uses
svn path=/trunk/kdepim/; revision=244918
- Delete messages during transfer
- Minor cleanups
- Do not display headers when you skip over messages
CCMAIL: 62943-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=243659
leads to the wrong list being traversed and folders not being closed,
that have been tempOpenFolder'd by the account -> RAM suckage
o add calls to displayProgress() in error paths to make sure all folders
that have been tempOpenFolder'd are closed
svn path=/trunk/kdepim/; revision=243346
1) Remove the limitation that a message can have only one status at a time.
2) Implement watch/ignore thread via message status flags.
ad 1:
- Message status is now kept as a bitfield, which means a message can now be
for example replied and forwarded as well as important at the same time.
- To keep the index format backward compatible and make the transition
painless, I've added a new index entry and added code to transfer the old
into the new format. That means that upgrading users should not notice
anything.
- I've tried to keep as much behavior as possible unchanged with regard to
what flag disables what other flag etc. There are two groups of flags:
read/unread/new/old influence each other, which means a message cannot be
new and read at the same time, for example, while the second group, namely
important, sent, queued, replied, and forwarded are toggled individually.
- Toggling a thread sets the messages status to the inverse of that of the
parent, which means that if you have a thread with some mails marked as
important and some not, the status is set according to that of the parent.
- Status is now kept when moving mails between folders in the same imap
account as well as between imap accounts.
ad 2:
- Watch and ignore are mutually exclusive, which means ignoring a thread
unsets its watched flag and the other way around.
- When sorting by status watched threads are at the top, ignored at the
bottom.
- Watch and ignore propagate via threading, which means that if a message
is threaded below a watched one, it becomes watched. Same for ignore.
- Moving a single mail out of a watched thread results in a new watched
thread of size 1 :)
- Similarly watch and ignore are possible on individual mail (threads
to be).
- Watching a thread does not currently mark new mails as important, nor
does ignoring delete new mails in the thread. These are possible
extensions, though, if we think them sensible.
svn path=/trunk/kdepim/; revision=235595
Carsten Burghardt
Till Adam
Ladislav Strojil
Marc Mutz
Ingo Klcker