This way you loose the information about empty parts and this breaks imap with LOD.
Nice side effect: signatures are checked correctly
CCMAIL: 71385@bugs.kde.org
svn path=/trunk/kdepim/; revision=275752
o readding the action to the menu
o making sure there is an actual slot behind the action
o preventing the command from being prematurely deleted
o making sure the KMMessage object used has a size and a serial number
CCMAIL: 71385-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=275585
This way the signature check works correctly when the message is opened in a separate readerwin.
Otherwise we got spurious empty Subject lines that broke the signature. A bit strange but it works.
CCMAIL: 70229-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=274199
Remaining issues: Passive popups show up in the left upper corner and taskbar flashing doesn't work.
Reviewed by Ingo Klöcker.
CCMAIL: 67017@bugs.kde.org
svn path=/trunk/kdepim/; revision=273515
Please excuse the addition of the new strings i18n("Message->","&Reply") and i18n("Reply to A&uthor..."). I hope it doesn't cause too much inconvenience for the translators.
CCMAIL:kde-i18n-doc@kde.org
svn path=/trunk/kdepim/; revision=272991
a message id. Also check if the subject md5 hash is the same as well as the
message id before assuming a duplicate.
This fails to remove duplicates in the following case, as pointed out by
Ingo:
> > The proposed patch won't remove all duplicates AFAICS. Example:
> > Message 1: Message-Id: a, Subject: a
> > Message 2: Message-Id: a, Subject: a
> > Message 3: Message-Id: a, Subject: b
> > Message 4: Message-Id: a, Subject: b
> >
> > AFAICS Message 2 will be removed (as duplicate of Message 1), but
> > Message 4 won't be removed.
It's probably a good idea to base duplicate removal on a hash computed over
several message headers, not just the message id. Post 3.2 material. I'll
close this bug as LATER as per Ingo's request since the most crucial
bug is fixed by this commit.
CCMAIL: 69657@bugs.kde.org
svn path=/trunk/kdepim/; revision=271609
by a clean signal/slot solution to notify the single components of a change
in the config dialog.
That fixes also #67484.
CCMAIL:67484-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=269130
active readerwindow to ask that for the attachmentstrategy but pass it
along with the folder job, so it is available when the mime structure
comes in with load on demand. Remove unused KMKernel::activeReaderWindow
which doesn't work in kontact anyhow.
CCMAIL: 67644-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=268877
- s/TRUE/true/ and s/FALSE/false/ in kmfilter.cpp
- replace deprecated KLineEditDlg by KInputDialog in kmfilterdlg.cpp
- fix a few What This texts in kmfilterdlg.cpp
svn path=/trunk/kdepim/; revision=262244
by popular request and add it to the Folder menu. Disable it there for non-
imap folders.
CCMAIL: 66123-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=259435
It would still be good to cancel imap jobs which are only kicked off for
the reader window when a message and/or folder is deselected and not just
ignore them. We don't want to cancel moves or filtering though, so those
need to be made discernable.
svn path=/trunk/kdepim/; revision=258420
is a KMMainWindow or kapp->config() otherwise. Will help fixing layout
and possibly other config related problems with the KMail part in Kontact.
While I was at it and complaining about the API, till jumped in saying:
<till> there are lots of public KActions and friend in kmmainwidget's
public api apparently for no good reason either
Your wish is my command, so this commit is also (and mostly) about API cleanup.
Okay'ed by Ingo.
svn path=/trunk/kdepim/; revision=256339
just the menu because the user might have them on the toolbar.
Btw, is there a reason for having all that stuff in the public api in
kmmainwidget.h?
CCMAIL: 64668-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=253687
Now that clears things up. How many times have you clicked on that hoping
to acquire used car stereo components from eastern europe? Or smokeables
from the friendly man from Marocco? Hm? Alex?
Brought to you by:
"ismail (cartman) donmez" <kde@myrealbox.com> (Bogazici University)
svn path=/trunk/kdepim/; revision=253083
#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
Ingo Klcker
Marc Mutz
Carsten Burghardt
Till Adam
Volker Krause
Daniel Molkentin
Tobias Koenig
George Staikos
Stephan Kulow
Bo Thorsen
Don Sanders
Waldo Bastian
Dirk Mueller