QMAX/QMIN -> qMax/qMin
I don't know what to do about Q_LONG and Q_ULONG because of the following code in qglobal.h:
#if defined(Q_OS_WIN64)
typedef __int64 Q_LONG; /* word up to 64 bit signed */
typedef unsigned __int64 Q_ULONG; /* word up to 64 bit unsigned */
#else
typedef long Q_LONG; /* word up to 64 bit signed */
typedef unsigned long Q_ULONG; /* word up to 64 bit unsigned */
#endif
Should I simply convert to (unsigned) long?
svn path=/trunk/KDE/kdepim/; revision=468393
kind, such that it is possible to trigger syncs from outside of KMail,
namely KOrganizer's resource view, via save.
svn path=/branches/KDE/3.5/kdepim/; revision=439727
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
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
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
turns out that it had been fixed in trunk already :/
bodypartformatter: close tempfile before starting korganizer, otherwise it'll see an empty file.
(https://intevation.de/roundup/kolab/issue816)
libkcal: set error message when parsing an empty file, fixes detailed-err-box with empty details.
svn path=/branches/kdepim/proko2/kdepim/; revision=428790
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
as discussed on kolab-format. This is backwards compatible, i.e. we can still load dist lists
that use the "contact" mimetype.
svn path=/branches/kdepim/proko2/kdepim/; revision=421173
annotations it does not matter either way, and with this it's easier
to recognize them in the web interface, etc.
svn path=/branches/kdepim/proko2/kdepim/; revision=420330
CVS commit by tilladam:
Make sure the imap resource is not prematurely disabled and that
annotation for folders that show up on the server suddenly (for example
when you sync a fresh client to an existing account) are fetched as
expected. That prevents varied unpleasantness and constipation.
svn path=/branches/KDE_3_4_BRANCH/kdepim/; revision=401866
annotation for folders that show up on the server suddenly (for example
when you sync a fresh client to an existing account) are fetched as
expected. That prevents varied unpleasantness and constipation.
svn path=/branches/proko2/kdepim/; revision=401778
were only used by the old imap resource which has gone off to wherever
retired code goes to play dominos and bitch about the kids these days.
svn path=/trunk/kdepim/; revision=369436
xml based kolab resource. This means that once I've committed the resource
part of this, the kolab resource can be configured to use ical/vcard or
xml format and work with both.
svn path=/trunk/kdepim/; revision=367575
Ingo Klcker
Till Adam
Laurent Montel
Stephan Binner
Reinhold Kainhofer
David Faure
Thomas Zander