which was handling that in the mainwindow. Remove duplicate and now unused
status handling in the KMSender and KMReaderWin classes.
svn path=/trunk/kdepim/; revision=334078
in KMHeaders used to use msgDict->getMsgSerNum( folder, index ) which fails
for search folders. Use msg->getMsgSerNum() instead. Remove now unused
parameter from the key generation.
Thanks, Scott, for insisting that this is broken, even though we all were
convinced it wasn't. :)
svn path=/trunk/kdepim/; revision=333830
the FolderStorage one, which necessitates some constification and
iteratorification (is that a word?) in a few places. Without this
KMFolderImap::removeMsg on lists was never called as the different
signature makes it an overload. Instead folderstorage deleted them one
by one using the removeMsg(msg) version.
Reduces server roundtrips when deleting n messages from n to 1, which is
especially noticable when expiring large amounts of mail. Way faster,
obviously.
svn path=/trunk/kdepim/; revision=333751
before being moved to an imap sent mail folder, is kept open, otherwise
the KMMsgBase pointers passed to the command become invalid. Introduce
KMCommand::keepFolderOpen( KMFolder* ) which opens a folder and adds it
to the list of folders to be closed by the dtor.
svn path=/trunk/kdepim/; revision=333462
Now we sent redirected messages which are conform to RFC 2822.
Thanks to Ingo for pointing me into the right direction.
CCMAIL: 51283-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=333330
o in doLoad() trigger downloading of all mail ( getMsg() doesn't suffice,
FolderJobs need to be kicked off ), return from the load() and collect
incoming mails in an accumulator object for each folder/resource. Once
all mails are there, push them to the resource itself via a new dcop signal
asyncLoadResult( const QStringList& lst, ... ) where it is parsed and
added to the store
o remove mResourceQuiet in KMailICalIfaceImpl, since it does not work
with addMsg() and friends being async. Instead, rely on the msgAdded()
and msgRemoved() signals we get from KMail instead of supressing them
o "lock" uids/messages by putting them in a map whenever they need to be
transferred and use that locking to avoid duplicate notifications (mail
add which we just uploaded ourselves, mail deleted which is part of an
update and being replaced) which was what mResourceQuiet did before
o compress updates for "locked" incidences. KOrganizer is very trigger happy
when it comes to sending updates, when editing a calendar entry I get 10 to
10 change notifications and updated icals, which would need to be uploaded
each time. Since that sucks, always keep the last update and forget the
intermediate ones if we are currently transferring that message anyhow.
Once we are done, check for updates and process them. This scheme
reduces the uploads per change to two, mostly. This will of course have to
be done right post 3.3. when Reinhold tells me beginChange() endChange()
will be available.
o keep a map of uids to sernums, which allows findMessageByUid() to work
without server roundtrips. The old code was iterating over all mails and
parsing the body looking for the right uid which is prohibitively slow over
online imap. This uses a bit of memory, but should scale much better and
improve performance.
If this shows regressions with dimap during the next few days, I'll revert,
but it's worth a try. Ok'd by Ingo.
svn path=/trunk/kdepim/; revision=333074
the message from the local sent mail (where it is placed for fallback) to
the imap folder by using a KMMoveCommand, which nicely encapsulates all
that. This avoids the folder constantly opening and closing during
processing of incoming data which makes KMail appear hung and consumes
massive amounts of cpu.
Ferdinand, can you confirm this fixes it?
CCMAIL: 84215-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=333060
KMMainWidget where the corresponding close was recently added by our man
Burghardt. Makes folder ref counting problems a lot easier to trace. Also
make sure the close comes after the folderSelected so we don't close before
that one can do its open.
svn path=/trunk/kdepim/; revision=333010
The maximum number of connections is configured using a configuration parameter in kmailrc called max-connections-per-host. A value of -1 (or the omission of the parameter altogether) means unlimited connections (ie same as current behvaiour). There is no means of configuring this facility via the GUI - you have to edit the kmailrc file.
svn path=/trunk/kdepim/; revision=332682
security page are not connected to the modify signal, so the apply button is not
enabled if you change them.
-> fixed.
svn path=/trunk/kdepim/; revision=331906
o assume the current number of folders in the account + 5% as the total
number of items, and tick them off as they come in, better than jumping
to 100% immediately and should be good enough for the common case of the
account folder listing not changing much
o add ImapAccountBase::folderCount() for convenience and constify some
stuff on the way
svn path=/trunk/kdepim/; revision=331842
But that's not true, with the KMMoveCommand in ExpireJob.
So refactored the "run this task now" support (as used by "Expire All Folders")
to still queue things (in case another task is running), but run the next job
immediately after the previous one, when there are pending immediate tasks.
Thanks to Andreas Gungl for his infinite patience and debugging help :)
CCMAIL: 83847-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=331755
If you don't want this, press "No", and the IMAP resource will be disabled.
-> make it so.
CCMAIL: 71390-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=331308
highlightMessage is called twice - the msg is transferInProgress==true - the message is not displayed
Fix: do not bounce the selection and make it identical to setCurrentItemByIndex
svn path=/trunk/kdepim/; revision=331270
(as is the case after the first startup), connect to finishedCheck() and try again then.
Had to add the config key TheIMAPResourceAccount for that.
svn path=/trunk/kdepim/; revision=331178
compact right away, we have to wait until the expiry job is done.
Found by looking at the debug output for #83847, but the bug is elsewhere.
svn path=/trunk/kdepim/; revision=331136
Till Adam
Script Kiddy
Carsten Burghardt
Andreas Gungl
Ingo Klcker
Martin Koller
Julian Rockey
David Faure
smail Dnmez
Daniel Molkentin