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
instead of hardcoding them in kmailicalifaceimpl.cpp.
Added custom header for the scheduling ID, but this might be a temporary solution.
svn path=/trunk/kdepim/; revision=358807
groupware folders. This was due (yet again) to readConfig losing the contents type of
the folder, so we need to call writeConfig just after setting it.
svn path=/trunk/kdepim/; revision=356777
Fixed the way the "standard groupware folders" are found when using the kolab xml storage:
instead of finding them by name, look for annotations like "event.default".
Fixed up mAnnotationFolderType and mAnnotationFolderTypeChanged, so that they
are only updated once we know if a folder is one of the standard groupware folders.
When the annotation isn't found and we try to create the folders, first check
for an existing folder with that name, and if it exists, change its contents type.
[This will happen to any existing proko2 user: you'll see a request for creating
the groupware folders, which will in fact only set the correct annotation on them]
Moved annotation values into kmailicalifaceimpl's array because one day Till
will need them from kmfolderimap :)
svn path=/trunk/kdepim/; revision=349074
isResourceFolder and hideResourceImapFolder into hideResourceFolder, since
the resource is not imap specific at all. Port all callers.
svn path=/trunk/kdepim/; revision=346967
new kolab resource needs, so I'll import that next. Unfortunately this
merge was somewhat invasive, so things might be slightly shaky still. I'll
debug that over the next few days, hopefully.
svn path=/trunk/kdepim/; revision=346785
Don't crash when a folder which is a resource folder is deleted, because
the resource is not removed properly from KOrganizer etc since no signals
were emitted in that case. Aggregate the folderRemoved signals of all
folder managers and emit a central folderRemoved(KMFolder*) which stuff
can listen to. Port the filter manager to that.
svn path=/trunk/kdepim/; revision=339422
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
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
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
The mResourceQuiet hack used here (to silence signals from kmfolder) broke
when the KMCommands were made async. Got rid of it, and introduced this instead:
+ // Ignore 'added' notifications for those incidences, we added them ourselves
+ // This is a temporary storage, between addIncidence and slotIncidenceAdded,
+ // which is called a bit later.
+ // We store the KMMessage* since we don't have a serial number yet.
+ QValueList<KMMessage*> mIgnoreAdded;
+ // Ignore 'deleted' notifications for those incidences, we deleted them ourselves
+ // This is a temporary storage, between deleteIncidence and slotIncidenceDeleted,
+ // which is called a bit later.
+ QValueList<Q_UINT32> mIgnoreDeleted;
svn path=/trunk/kdepim/; revision=321475
Thanks to Till for the advice on how to do that (storing folder id and using a KMMoveCommand)
Added kmkernel::findFolderById() to avoid copy/pasting yet another time
the code that looks in the 3 foldermgrs; ported the existing code to that.
CCMAIL: 43218-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=311024
Till Adam
David Faure
Bo Thorsen
Daniel Molkentin