Backporting lots of stuff from 3.5
Better KPaintInfo struct.
New helper methods from 3.5
Changes to context menu in mainwidget.
TODO: test painting of the leftmost column on a different
machine.
#1 Check if ToDo Icon is present or not.
#2 Check if the painting is borked or not.
svn path=/branches/kdepim/proko2/kdepim/; revision=556100
- kmail/imapaccountbase.cpp:1102
If line 1092 gets executed and also 1102, then the second crashes.
- kmail/kmmsgdict.cpp:248
If folder is NULL as indicated by line 244, then line 248 crashes.
- kmail/kmmsgdict.cpp:214
If folder is NULL as indicated by line 208, then line 214,225, crashes.
- kmail/renamejob.cpp:64
If storage is NULL as indicated by line 57, then line 62 crashes.
Lines where the operator preference between & and == leads to an error.
- kmail/kmmsgbase.cpp:873
- kmail/kmfolderimap.cpp:876
If f is NULL as indicated by line 869, then line 876 crashes.
- kmail/kmsender.cpp:362
If sentFolder is NULL as indicated by line 340, then line 362, 367
crashes.
Thanks to Christoph for working on this.
svn path=/branches/KDE/3.5/kdepim/; revision=530119
by a clear directive, that Ignored overrides New and Unread.
This is implemented in the isRead() and related methods.
BUG:97314
svn path=/branches/KDE/3.5/kdepim/; revision=463672
stripped of their old UID, by making sure the sernum mechanim is not
used for the complete flag, but there is a real bool per msgbase. This
one was fixed in trunk a while ago already ...
svn path=/branches/kdepim/proko2/kdepim/; revision=455461
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
Pradeepto Bhattacharya
David Faure
Ismail Onur Filiz
Martin Koller
Andreas Gungl
Ingo Klcker
Till Adam
Bar Metin
Mario Teijeiro Otero
Laurent Montel
Martin Kbele
Carsten Burghardt
Stephan Kulow
Don Sanders
Dirk Mueller
Marc Mutz