lead to a slow down when loading messages (and they weren't doing anything
then, since getMsgSerNum()==0).
svn path=/branches/KDE_3_3_BRANCH/kdepim/; revision=361959
when simply opening mail folders) : don't look for the serial numbers
of messages that haven't been inserted into a folder yet, it can't find one,
and it's slow every time. Note that assign() is only called on construction
(or soon after), never on totally-unrelated instances.
svn path=/trunk/kdepim/; revision=361937
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
compilation flags :)
(I knew --diable-debug makes a difference, but I wasn't really aware it flies
for users ;)
svn path=/trunk/kdepim/; revision=270960
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
account when sorting by status (doh) and making the sort key generation
a bit more intuitive. That is of course entirely subjective, so if someone
has better ideas how to order them, please speak up.
svn path=/trunk/kdepim/; revision=257730
#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
understand it.
However, comparing an unsigned value to see if it is negative makes no sense.
CCMAIL: kmail@kde.org
svn path=/trunk/kdepim/; revision=241901
- they operate on the string stipped of whitespace at start and end
- base64EncodedMD5("") returns ""
The latter change is necessary, because otherwise the empty string hashes
to something not empty and a message without a In-Reply-To header suddenly
has msg->replyToIdMD5().isEmpty() == false. That means that it thinks that
it needs to be threaded under a message without a Message-ID header
(happens, trust me) because the md5 hash of that is the same (that of the
empty string) and all manner of mischief ensues. People file bug reports
that threading sucks, I develop an ulcer and Lance Armstrong wins the
Tour de France for the fifth time in a row. We do not want that.
svn path=/trunk/kdepim/; revision=240984
- proper scoping
- guard clauses (fixes possible crash when aStr.isNull() = true)
- replace if (valid) {...} if (valid) {...} if (valid) {...} with
goto's where formerly the bool valid was set to false
- constness fixes
svn path=/trunk/kdepim/; revision=237614
- When reading the legacy status field, set all messages that are not new
or unread as read, so they don't end up having unknown status if the user
unsets the only flag they have, for example important.
svn path=/trunk/kdepim/; revision=236048
mail notification for mail in ignored threads as a side effect. I strongly
suspect this is the desired behavior.
svn path=/trunk/kdepim/; revision=236026
Till Adam
Mario Teijeiro Otero
David Faure
Laurent Montel
Ingo Klcker
Martin Kbele
Carsten Burghardt
Stephan Kulow
Don Sanders
Dirk Mueller
Marc Mutz
George Staikos