- Support for special jobs in kleo
- Support for more protocols than opengpg and smime in kleo
- Removing old code from cryptplug*
- Improved GUI design in dynamic crypto dialog
- Chiasmus support (german-government crypto)
svn path=/trunk/KDE/kdepim/certmanager/; revision=434915
ran across this while doing a very similar dialog and wondering why my
buttons where at the bottom, instead of at the top. Well, as Marc
educates me, the children are added on childEvent, which means after the
stretch is added. When I went back to this dialog to check why it works
here, I noticed that it doesn't. ;)
svn path=/trunk/KDE/kdepim/; revision=434205
if the foldertype in the config differs from what the message in KMail
contains, convert on write to the set format.
This is necessary as the resource has no way of knowing what the
old format of the incidence was, since only KMail has access to the
actual mail in the folder. That means that the resource has to
assume the folder's format is the incidences, when writing,
while the kmail end can recitify things in the mail when it sees
that mail contents and storage format do not align. In effect this will
result in incidences of one type in folders configured to use the other
one being converted if they are edited. As long as they are not edited,
nothing changes, reading is transparent.
This also fixes the problem of ical incidences in xml folders suddenly
losing their payload on change and being replaced with a crippled
xml-style mail.
svn path=/trunk/KDE/kdepim/; revision=434018
we don't abort the filter creation, but we use the From: header
of the message directly in the filter.
BUGS: 105405
svn path=/trunk/KDE/kdepim/; revision=433367
Improve the sent mail folder logic and the readOnly protection to
first try the folder specified in the mail, then if there was none, or
it's not usable, try the identity one, and if that also fails, the
system one.
svn path=/branches/kdepim/proko2/kdepim/; revision=433147
first try the folder specified in the mail, then if there was none, or
it's not usable, try the identity one, and if that also fails, the
system one.
svn path=/trunk/KDE/kdepim/; revision=433145
on, by setting the involved folderstorage's search pointers to 0 and
checking them. Can't use a QGuardedPtr, since the searchpatterns aren't
QObjects. Const-ify patterns and some detabification.
svn path=/trunk/KDE/kdepim/; revision=432984
listen to nameChanged. slotRepaint -> slotIconsChanged, which expresses
what it really does. Add commented out debugging message box, since I
have it in there atm, and can't be arsed to patch it out. ;)
svn path=/trunk/KDE/kdepim/; revision=432809
looks nicer in web clients, makes no difference in kmail.
Fixed a bug in my recent groupware-folder-detection patch.
svn path=/trunk/KDE/kdepim/; revision=432788
instead of "kmail will create them", show exactly which ones were found and which ones
must be created. The "kmail will create them" dialog remains for the case where no
groupware folder was found.
svn path=/trunk/KDE/kdepim/; revision=432775
SVN commit 432741 by tilladam:
If the user has managed to put a message into a folder that she now (on
sync) has no longer sufficient rights to put mails into, pop up a
helpful dialog explaining the issue and offering to move the mails in
question into another folder. If the user decides to move them away,
show a folder selector and move. Then continue syncing.
svn path=/branches/kdepim/proko2/kdepim/; revision=432763
SVN commit 432750 by tilladam:
If the user has managed to delete a mail from a read only folder,
through gui bugs, or that particular skill users have to achieve the
impossible, don't attempt to delete on the server, but simply
re-download. This also helps if the folder goes from "i can delete" to
"i can't delete" between syncs.
svn path=/branches/kdepim/proko2/kdepim/; revision=432761
through gui bugs, or that particular skill users have to achieve the
impossible, don't attempt to delete on the server, but simply
re-download. This also helps if the folder goes from "i can delete" to
"i can't delete" between syncs.
svn path=/trunk/KDE/kdepim/; revision=432750
sync) has no longer sufficient rights to put mails into, pop up a
helpful dialog explaining the issue and offering to move the mails in
question into another folder. If the user decides to move them away,
show a folder selector and move. Then continue syncing.
svn path=/trunk/KDE/kdepim/; revision=432741
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
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.
svn path=/branches/kdepim/proko2/kdepim/; revision=432536