- add storage property "noChildren" (guess what it does)
- allow the creation of subfolders of system folders (except the outbox)
- the content of the belongs-to combox in the folderdialog looks like the foldertree
- get rid of old stuff in kmfoldertree
- kmfoldertree is the parent of kmfolderdialog
...and fix the mailinglist handling
CCMAIL: 11903-done@bugs.kde.org
CCMAIL: 37139-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=295688
listing telling us about it, trust the server and set the mail to new
or unread no matter what our local index tells us the status is. This
is necessary because if we set a message to read locally but fail to set
\SEEN on the server for some reason, the count of unread mails will be
henceforth out of sync. That will not do, now, will it?
svn path=/trunk/kdepim/; revision=291996
o Enable the expiry settings in the folder properties for imap and dimap
folders.
o Add some folderjob infrastructure to imapjob and cachedimapjob along the
way.
o Fix a few folderstorage crashes waiting to happen.
Only manual expiry of imap/dimap folders is hooked in, but we could just
as well hook the imap and dimap foldermanagers into the autoexpiry on
shutdown thingie. For dimap that should be as safe or unsafe as for maildir
and for imap it's as save or unsafe as deleting a bunch of messages and
immediately closing KMail. Opinions?
This commit is dedicated to the hardest working man in show business,
S. Kulow whose birthday it is today.
Let's give it up for the man:
o/` For he's a jolly good RD, for he's a jolly good RD, for he's a jolly
good RD ... which nobody can't deny .. o|`
CCMAIL: 48189-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=290404
o remove duplicate in KMFolderCachedImap
o use the one from KMFolderImap everywhere
o add const to parameters as we go
Rinse, lather, repeat.
svn path=/trunk/kdepim/; revision=289324
You don't need getMsg anymore for the UID and LOD can check the size without loading the header.
I updated the online imap folder but dimap should also use the new code.
svn path=/trunk/kdepim/; revision=288206
when the deleteMessage method is called on a message that does not have
a UID, for whatever reason.
Ouch.
Now we need to find out why the message has no uid.
Ingo, backport, I assume?
CCMAIL: 74017@bugs.kde.org
svn path=/trunk/kdepim/; revision=284955
in getMsg broke things. As the msgLength is not saved in the index I have to take a different approach to override LOD for
small messages: after the header was downloaded we check the size again and then fall back to loading "TEXT".
CCMAIL: 72432-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=279791
Actually delete the folder in this case and do not block the new-mail-checks.
Fix Yet Another Disappearing Inbox.
Can anybody please commit this to osnabrueck_branch?
CCMAIL: 72031-done@bugs.kde.org
CCMAIL: coolo@kde.org
svn path=/trunk/kdepim/; revision=278028
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
Carsten Burghardt
Till Adam
Bo Thorsen
Ingo Klcker
Ladislav Strojil
Marc Mutz