objects. I've left the MessageProperty implementation, since the
attribute is transient, in a way. Hm. Opinions?
svn path=/trunk/KDE/kdepim/; revision=430877
of KMsgBase and into KMMessage, they are exclusively used on those and
don't make sense for MsgBase objects. Implement them using boolean
bits instead of the MessageProperty map, as discussed a while ago on
kmail-devel.
svn path=/trunk/KDE/kdepim/; revision=430849
here: http://lists.kde.org/?l=kmail-devel&m=111945756024656&w=2
I've changed the KMMsgDict::instance() to return a pointer instead of a
reference, compared to the patch I posted, after valid criticism from
Marc that the pattern is generally used with a pointer, in KDE, so it's
better not to surprise people here.
svn path=/trunk/KDE/kdepim/; revision=428560
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
Volker Krause
Laurent Montel
Ingo Klcker
Till Adam
Bar Metin
Mario Teijeiro Otero
David Faure
Martin Kbele
Carsten Burghardt
Stephan Kulow
Don Sanders
Dirk Mueller
Marc Mutz
George Staikos