SVN commit 640463 by pradeepto:
Kolab/issue1384 and http://bugs.kde.org/show_bug.cgi?id=108939 -
Forward porting Till's proko2 implementation.
Commits #s 581382,588340,609388.
Don't allow base64 or qp encoding for message attachements, such
as when forwarding. (Kolab Issue 1384)
Make sure attached emails are never encoded in anything but 7 or 8 bit.
(Kolab Issue 1384)
Don't base64 encode forwarded messages, the rfc disallows it.
(Kolab Issue 1384)
TODO : forward port to pim+
CCMAIL : winterz@kde.org
svn path=/branches/KDE/3.5/kdepim/; revision=640496
Forward porting Till's proko2 implementation.
Commits #s 581382,588340,609388.
Don't allow base64 or qp encoding for message attachements, such
as when forwarding. (Kolab Issue 1384)
Make sure attached emails are never encoded in anything but 7 or 8 bit.
(Kolab Issue 1384)
Don't base64 encode forwarded messages, the rfc disallows it.
(Kolab Issue 1384)
TODO : forward port to pim+ and branch/3.5/kdepim
svn path=/branches/kdepim/enterprise/kdepim/; revision=640463
Improve speed (mainly killing the reparsing which was done in KMMessage::asSendableString())
Kolab issue 1222
svn path=/branches/KDE/3.5/kdepim/; revision=633978
Improve speed (mainly killing the reparsing which was done in KMMessage::asSendableString())
Kolab issue 1222
svn path=/branches/kdepim/enterprise/kdepim/; revision=633977
The time between Ctrl+Enter and the composer window disappearing is noticeably shorter (it's almost immediate now), especially when no crypto is used.
This is part of the contracted work for kolab issue 1222 ("out of memory when signing large attachments").
svn path=/branches/KDE/3.5/kdepim/; revision=633777
This is part of the contracted work for kolab issue 1222 ("out of memory when signing large attachments").
svn path=/branches/kdepim/enterprise/kdepim/; revision=633625
RFC 2231 defines an enhanced encoding for attachment filenames, and thunderbird
apparently implemented this encoding. RFC 2231 allows one field to be split
across multiple numbered entries of the form fieldname*0=....;
fieldname*1=...; fieldname*2=...; or fieldname*0=....; fieldname*1=...; fieldname*2=...;
All these entries first need to be concatenated to form the full value of the field.
Here's a real-life example:
--------------060807060608070200030605
Content-Type: application/vnd.ms-excel;
name*0*=ISO-8859-15''%41%46%42%D6%20%42%65%73%65%74%7A%75%6E%67%73%6C%69;
name*1*=%73%74%65%20%53%74%61%6E%64%20%32%30%30%36%2D%31%32%2D%31%39%2E;
name*2*=%78%6C%73
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename*0*=ISO-8859-15''%41%46%42%D6%20%42%65%73%65%74%7A%75%6E%67%73%6C;
filename*1*=%69%73%74%65%20%53%74%61%6E%64%20%32%30%30%36%2D%31%32%2D%31;
filename*2*=%39%2E%78%6C%73
As a result, KMail shows %39%2E%78%6C%73 as the file name in both the message
preview panel as well as in the mime tree.
With this patch, KMail correctly shows the proper filename.
The patch adds one static method to collect all parts of rfc 2231-encoded
params into one single string. That method is then used in two different
places for the name and the filename props.
One minor problem remains, though: As the mime library does not have support
for rfc2231 encoded attachments, the message is not shown with the attachment
icon in the message list.
BUG:108091
BUG:113100
svn path=/branches/KDE/3.5/kdepim/; revision=622052
Suppose headers charset from content-type header if headers not
properly encoded. If content-type charset is "us-ascii", use "utf-8"
instead. Write maildir and mbox indexes in right encoding.
BUGS:98079
svn path=/branches/KDE/3.5/kdepim/; revision=614058
Get attachment icon from file name if not available from Content-Type
(Using KMimeType::findByPath as suggested by David Faure)
CCBUG: 35836
svn path=/branches/KDE/3.5/kdepim/; revision=608103
override encoding. Propagate override encodings properly to external
reader windows and printing, and make a new page in the configuration
dialog for reader window specific things. Rename the tab for the message
list settings to "Message List" from "Headers". Proko2 issue866.
svn path=/branches/kdepim/proko2/kdepim/; revision=489969
were "saved" to kmailrc, but kmailrc wasn't synced, so in case of a kmail crash, X crash, power failure, kernel oops...
the settings would be lost, and on the next kmail restart very strange errors would happen when syncing
(can't create folder, folder already there, folder missing, etc.)
The solution: sync(). But while being at it I implemented buffering of sync requests
which was a TODO in kmkernel, but did it in GlobalSettings as Till suggested;
which in turn means we need our own GlobalSettings inheriting GlobalSettingsBase,
and the code lacked ::self()-> in many places to allow that.
srcdir!=builddir users: don't forget to delete globalsettings.{cpp,h} from the builddir
since it's not generated anymore!
CCMAIL: kmail-devel@kde.org
svn path=/trunk/KDE/kdepim/; revision=432538
since we don't need to call Codec::codecForName for it.
Also fixed a compiler warning, the return value from duplicate() was never set, and never used.
svn path=/trunk/kdepim/; revision=360398
since we don't need to call Codec::codecForName for it.
Also fixed a compiler warning, the return value from duplicate() was never set, and never used.
Approved by Marc Mutz.
svn path=/branches/KDE_3_3_BRANCH/kdepim/; revision=360383
and storing them in a kolab resource. First speed problem: this kdWarning statement
evaluates kdBacktrace each time, even if it won't print it.
svn path=/branches/KDE_3_3_BRANCH/kdepim/; revision=360372
Fix PGP/MIME encrypting messages which are BCC'ed. The problem was that KMMessagePart contains a QByteArray which is explicitely shared. Therefore simply copying a KMMessagePart with the copy c'tor for getting a temporary copy isn't possible. Implementing and using a duplicate method fixes the problem.
BUG: 92412
svn path=/branches/KDE_3_3_BRANCH/kdepim/; revision=359105
Properly clear the KMMsgPart before it's filled with the values of the DwBodyPart. This fixes bug 87198 (Sending (of new) a e-mail with kmail for kde-3.3 the name of the file attached, some times, it comes lost) which was caused by the fact that we reused the same KMMsgPart object in order to add all attachments to a forwarded message.
svn path=/branches/KDE_3_3_BRANCH/kdepim/; revision=348023
#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
Default to local encoding if no charset is specified for a message part. Patch by Toyohiro Asukai <toyohiro@ksmplus.com>
CCMAIL: 56570-fixed@bugs.kde.org
svn path=/trunk/kdepim/; revision=217435
kmmessage.*:
- Add static QValueList<int> determineAllowedCtes( const KMime::CharFreq& cf,
bool allow8Bit,
bool willBeSigned );
This function returns a list of ctes which can be used to encode a
message/message part with the given result of the character frequency
analysis and under the given restrictions. This function is introduced
to remove code quadruplication (the same code was used twice in
KMMessage and twice in KMMessagePart).
kmmessage.* and kmmsgpart.*:
- Add bool willBeSigned parameter to the setBodyAndGuessCte functions.
- Get rid of the quadupled code and instead use the above mentioned
static function.
kmcomposewin.cpp:
- Make use of the enhanced setBodyAndGuessCte functions.
Patch as posted to the KMail mailing list on Dec 22 (except for the 'const' in determineAllowedCtes(...)).
svn path=/trunk/kdepim/; revision=201086
Volker Krause
Frank Osterfeld
Pradeepto Bhattacharya
David Faure
Reinhold Kainhofer
Allen Winter
Jonathan Marten
Till Adam
Ingo Klcker
Thomas Zander
Stephan Kulow
Marc Mutz
Carsten Burghardt
Zack Rusin
Bo Thorsen
Daniel Molkentin