- extend the interface of the class to simplify it's handling
- partial port of existing kmail code to use the new class
svn path=/trunk/KDE/kdepim/; revision=474940
The simple status variable has been replaced by a class
which encapsulates the internal representation of the status
flags as well as the logic to keep the integrity.
svn path=/trunk/KDE/kdepim/; revision=474533
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
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
of a newly created one to insert quote chars / past quote chars
Ahh; removing code to fix problems is always my favorite solution :-)
svn path=/trunk/KDE/kdepim/; revision=424841
SVN commit 423824 by tilladam:
Make sure that the cc is properly taken into account during identity
detection on replies.
svn path=/branches/kdepim/proko2/kdepim/; revision=424376
CVS commit by tilladam:
When inline forwarding a mail consisting of only a top level body part,
extract that body part into an attachment of a newly created multipart/
mixed mail and create a new text part clearly identifying the mail as
a forward.
svn path=/trunk/kdepim/; revision=402419
extract that body part into an attachment of a newly created multipart/
mixed mail and create a new text part clearly identifying the mail as
a forward.
svn path=/branches/proko2/kdepim/; revision=402399
when inline forwarding because otherwise they are falsely inherited
by the fowarded mail. I've tried to thoroughly regression test it, and
even inline forwarding opaque smime signed and encrypted mails with
attachments still works. If you are using inline forwarding, please give
it a try. If it works in all cases, we can backport it.
svn path=/trunk/kdepim/; revision=398184
this means that it is not so easy to mistype an email address and
thus causing strange errors, for example unbalanced > are not allowed
and many other cases are also caught by this validation.
BUG:95183
BUG:29571
BUG:93703
BUG:71680
BUG:74032
BUG:79169
svn path=/trunk/kdepim/; revision=391270
with attachments change the strategy for assembling the forward mail from
"make a new mail, copy the text body with some fluff, iterate over attach-
ments and attach them to the mail" to "copy the original mail, including
all attachments (possibly inline, for opaque smime), adjust the text part
in the composer, set subject, from, to as needed". That's not only simpler
but leaves the actual parsing of the message that is being forwarded to the
ObjectTreeParser in the messagecompser which can deal with things like
opaque signed mails and construct virtual bodypart for its contents. This
should finally fix aegypten isse 39/266 for good. (Yeah, right ;).
svn path=/trunk/kdepim/; revision=388759
with attachments change the strategy for assembling the forward mail from
"make a new mail, copy the text body with some fluff, iterate over attach-
ments and attach them to the mail" to "copy the original mail, including
all attachments (possibly inline, for opaque smime), adjust the text part
in the composer, set subject, from, to as needed". That's not only simpler
but leaves the actual parsing of the message that is being forwarded to the
ObjectTreeParser in the messagecompser which can deal with things like
opaque signed mails and construct virtual bodypart for its contents. This
should finally fix aegypten isse 39/266 for good. (Yeah, right ;).
svn path=/branches/proko2/kdepim/; revision=388755
Andreas Gungl
Laurent Montel
Till Adam
Volker Krause
Ingo Klcker
David Faure
Marc Mutz
Thomas Zander
Matt Douhan
George Staikos
Matthias Kretz
Carsten Burghardt