kolab resource doesn't try to parse ical.
But I can't fix the ical resource since this is still in proko2 branch...
svn path=/branches/proko2/kdepim/; revision=338591
got a dialog on startup asking to make the resource folders. Even though
the folders were already there. This is fixed here.
I would like to check this fix into HEAD, 3_2_BRANCH and 3_3_BRANCH since
it's a PITA for those hit by it. Is that OK?
CCMAIL: kmail-devel@kde.org
svn path=/branches/proko2/kdepim/; revision=337525
o in doLoad() trigger downloading of all mail ( getMsg() doesn't suffice,
FolderJobs need to be kicked off ), return from the load() and collect
incoming mails in an accumulator object for each folder/resource. Once
all mails are there, push them to the resource itself via a new dcop signal
asyncLoadResult( const QStringList& lst, ... ) where it is parsed and
added to the store
o remove mResourceQuiet in KMailICalIfaceImpl, since it does not work
with addMsg() and friends being async. Instead, rely on the msgAdded()
and msgRemoved() signals we get from KMail instead of supressing them
o "lock" uids/messages by putting them in a map whenever they need to be
transferred and use that locking to avoid duplicate notifications (mail
add which we just uploaded ourselves, mail deleted which is part of an
update and being replaced) which was what mResourceQuiet did before
o compress updates for "locked" incidences. KOrganizer is very trigger happy
when it comes to sending updates, when editing a calendar entry I get 10 to
10 change notifications and updated icals, which would need to be uploaded
each time. Since that sucks, always keep the last update and forget the
intermediate ones if we are currently transferring that message anyhow.
Once we are done, check for updates and process them. This scheme
reduces the uploads per change to two, mostly. This will of course have to
be done right post 3.3. when Reinhold tells me beginChange() endChange()
will be available.
o keep a map of uids to sernums, which allows findMessageByUid() to work
without server roundtrips. The old code was iterating over all mails and
parsing the body looking for the right uid which is prohibitively slow over
online imap. This uses a bit of memory, but should scale much better and
improve performance.
If this shows regressions with dimap during the next few days, I'll revert,
but it's worth a try. Ok'd by Ingo.
svn path=/trunk/kdepim/; revision=333074
/home/test/.kde/share/apps/kmail/dimap/.1862587655.directory/.INBOX.directory/Notes
and
/home/test/.kde/share/apps/kmail/dimap/.1747989171.directory/.INBOX.directory/Notes
:)
It now looks like "<account name> INBOX/Notes".
Needed to use dcopidlng to parse the iface file, because of the ctors in the struct.
But dcopidlng has a bug with #include "foo.h"
svn path=/branches/proko2/kdepim/; revision=331560
Find all extra folders in readConfig - so that they are found on startup
Fixed another problem with base64 encoding
svn path=/branches/proko2/kdepim/; revision=331450
If you don't want this, press "No", and the IMAP resource will be disabled.
-> make it so.
CCMAIL: 71390-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=331308
(as is the case after the first startup), connect to finishedCheck() and try again then.
Had to add the config key TheIMAPResourceAccount for that.
svn path=/trunk/kdepim/; revision=331178
(as is the case after the first startup), connect to finishedCheck() and try again then.
Had to add the config key TheIMAPResourceAccount for that.
svn path=/branches/proko2/kdepim/; revision=331154
ressource because a) I don't see a need to override the ref counting and
b) it crashes when one of the ressource folders is selected and contains
at least one message, because KMHeaders does not like saving state on a
closed folder. Bo, if I'm missing something here, please yell at me
( and fix the crash some other way ;).
svn path=/trunk/kdepim/; revision=330356
imap account. Set the account of the newly created folders.
This fixes the crash, but the folders are still not created properly,
especially on startup, as the account is potentially not connected yet.
Will look into that next.
CCMAIL: 85298-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=330304
(mimelib is really not suited for updating stuff, it's meant for reading or writing only)
Similary, added a cleanupHeader call to make the headers available later on.
Added StorageUnknown answer to storageFormat() for clarity.
Ported more methods to findBodyPart().
svn path=/branches/proko2/kdepim/; revision=330071
holding them was deleted (or the parent folder of the groupware ones was removed),
that makes no sense.
svn path=/branches/proko2/kdepim/; revision=326815
(in particular when using dnd in kmail). Factorize code, find uid by parsing XML, etc.
Also fixed wrong logic where many folders were registered as "extra folders" erroneously.
But I wonder if now they can never be registered, due to mUseResourceImap being false
on startup...
svn path=/branches/proko2/kdepim/; revision=326151
Spotted a few wrong return values and a wrong folderById instead of folderResource in deleteIncidenceKolab.
svn path=/branches/proko2/kdepim/; revision=324923
David Faure
Bo Thorsen
Till Adam
Karl-Heinz Zimmer