CVS commit by tilladam:
Fix issue 139 by using the mechanism we use for setting the replied and
forwarded status after a mail has been sent succesfully to move the mail
that originally triggered the sending of the accept/decline mail, whose
serial number is remembered in a link header to the trash folder configured
for that account. In other words, if you click to accept an invitation, and
then send the generated reply, the invitation mail will automagically go
away.
svn path=/trunk/kdepim/; revision=347299
forwarded status after a mail has been sent succesfully to move the mail
that originally triggered the sending of the accept/decline mail, whose
serial number is remembered in a link header to the trash folder configured
for that account. In other words, if you click to accept an invitation, and
then send the generated reply, the invitation mail will automagically go
away.
svn path=/branches/KDE_3_3_BRANCH/kdepim/; revision=347297
Works for mail accounts and SMTP servers, already stored passowrds are migrated to the wallet.
CCMAIL: 76097-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=342067
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
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
* When the user requests compaction of a folder from the RMB, always compact
(even if !needsCompaction), and ensure the final statusbar message shows up
(due to kmheaders polluting it, I had to save/restore it in 2 places).
* When compacting outbox after sending mails, don't tell the user.
This made me stumble upon strange code in kmsender.cpp: if count<0, expunge.
Ingo and I agree that this was meant to be if count==0, expunge.
svn path=/trunk/kdepim/; revision=319419
to libkdepim. Removed dependency on KMMainWidget by using a signal from ProgressDialog.
This also fixes the bug Till reported, where closing the progressdialog with
the cross wouldn't make the arrow look up again.
svn path=/trunk/kdepim/; revision=316885
ProgressItems. Add some Q_ASSERTS a la David. Remove the now unused
method. Make message up- and download cancellable.
One remaining issue: displayProgress() was (ab)used to reset the idle
timeout, which eventually disconnects the slave. Where should this
resetting be done now? In the ImapJob dtor, maybe?
svn path=/trunk/kdepim/; revision=313541
(better than <foo.h>, especially when systems could have an identity.h somewhere)
A kconfig_update script moves the identities from kmailrc to emailidentities
svn path=/trunk/kdepim/; revision=311347
which removes it from the current folder and re-adds it, thereby emitting
msgAdded signals which increase the message count in the folder. This leads
to strange "1 of 2 messages sent" status messages. Do filtering under
msg->parent()->quiet(true) which prevents the emitting of those signals.
This is somewhat hackish but will be more cleanly solved with the new
filter manager which should file the mails into the sent mail folder
directly.
OK'd by Ingo.
svn path=/trunk/kdepim/; revision=278413
folders tempOpened by filters are closed prematurely. They are now only
closed when there is no more filter using the filter manager.
svn path=/trunk/kdepim/; revision=262221
sending code was still assuming we did. That led to unpleasantness when the
sent-mail folder was prematurely closed due to the refcounting being one
off.
Luis, thanks for the bug report and logs.
CCMAIL: 65704-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=260276
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
#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
Till Adam
Karl-Heinz Zimmer
Szombathelyi Gyrgy
Holger Freyther
Volker Krause
Andreas Gungl
smail Dnmez
Stephan Binner
Ingo Klcker
David Faure
Stephan Kulow
Dirk Mueller
Bo Thorsen
Ladislav Strojil
Marc Mutz
Carsten Burghardt
Zack Rusin