when applying an ad-hoc filter via Message->Apply Filter to
many, many messages.
Now you can guess when your KMail will be back to normal work.
svn path=/trunk/KDE/kdepim/; revision=483598
dialog.
Use action scheduler for manual filtering and for online IMAP
filtering when an online IMAP folder is specified as the
target of any filter action.
Set the action scheduler account in KMAcctImap,
so that per account filtering works
with the action scheduler (oops).
In the old filter system, KMFilterMgr explicityly
ignore online IMAP targets.
GUI: Online IMAP folders are now shown in the filter dialog.
GUI: An information dialog is shown when an online IMAP
GUI: folder is specified as the target of a filter action
GUI: in the filter dialog.
svn path=/branches/KDE/3.5/kdepim/; revision=451939
even when it is temporary not available or deleted;
the GUI indicates if the folder is not available
BUG:110118
GUI:
svn path=/branches/KDE/3.5/kdepim/; revision=449177
and commit the action scheduler.
To try out the action scheduler (which is disabled by default) add an
action-scheduler=true entry to the [General] section of your kmailrc
file.
To help me do this I've added a private dcop method to help me monitor
the health of the action scheduler, you can try it by:
dcop kmail KMailIface "debugScheduler()"
svn path=/branches/KDE/3.5/kdepim/; revision=443111
- Make KMFilterActionWithFolder::displayString() return the nice translated folder name instead of the internal folder name. Non-generic implementation of displayString() for the other filter actions will have to wait till after the string freeze.
- Use the new displayString() method for creating a nicer log message in the filter log.
svn path=/trunk/kdepim/; revision=391484
so I've chosen the shorter way as a first implementation.
File Into Folder is renamed to Move Into Folder to provide the
usual Move / Copy pattern to the users.
FEATURE: 59327
svn path=/trunk/kdepim/; revision=371164
when initiated via menu or hotkey (the redirect filter action
has already been fixed for 3.3).
See http://bugs.kde.org/show_bug.cgi?id=88473 and duplicates.
The dialog which collects the addresses needs further
improvements though.
svn path=/trunk/kdepim/; revision=350099
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
(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
new message is constructed and returned which has a new set of headers.
Consequently there is no X-UID header anymore. If the message is then left
in the same folder and not moved somewhere else, the original mail is
removed from the folder on the server and the new one uploaded. To figure
out which mail to remove, the (now missing) X-UID header is looked at.
That is not there -> no uid -> message is not delete (used to be folder is
expunged). To avoid that, restore the X-UID header after the pipe through
to make sure it's there. Not really correct, technically, but I can't
think of another reliable way to fix this.
Thanks a lot to Arnaud Burlet for helping me track this bugger down and
testing.
Backport?
CCMAIL: 74017-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=285431
This should fix a bug with ad hoc filters crashing when they move a message
to a different folder.
And also fix the bug/limitation that the move to folder action has to
come last in the list of filter actions for a filter.
This commit doesn't really use the action scheduler, code to use the
action scheduler in kmheaders and kmcommands is commented out.
I've been testing this code for a few weeks now. The changes to the
assignment operators in the kmmessage and kmmsgbase classes are the
changes I'm most concerned about here.
svn path=/trunk/kdepim/; revision=264912
#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
Andreas Gungl
Laurent Montel
Ingo Klcker
Volker Krause
Don Sanders
Marc Mutz
Carsten Burghardt
Till Adam
Bo Thorsen
Stephan Binner
David Faure