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
- Return the real type of extra resource folders
- Listen to extra folders signals from adding and removing messages
svn path=/trunk/kdepim/; revision=311011
this texts into the kmail.kcfg in the hope that they get more love there.
Add a note in the startupwizard that the stuff in there accessing options
is no longer up to date. Make kconfig_compiler generate item accessors and
make it import user texts.
These options are new, right? No need for update scripts because of the
renaming?
svn path=/trunk/kdepim/; revision=301183
#define kernel KMKernel::self()
to
#define kmkernel KMKernel::self()
because 'kernel' was a much to general term. We really shouldn't repeat the mistakes of the X developers.
I noticed this problem when I played around with KImageEffects. kimageeffects.h contains 'kernel' as parameter of some methods and so the compilation had to fail. We won't need KImageEffects in the near future, but at least we are now prepared and a clash with another 'kernel' can't happen anymore.
svn path=/trunk/kdepim/; revision=252621
In kroupware_branch, it is known for certain that all korganizer code
is stored in KMail folders. We don't want that in HEAD, so this means
a change in the way things work.
The old kroupware way to receive appointments:
- KMail receives a mail with an invitation
- The invitation is decoded with a hack in KMGroupware, and the user
is asked to decide upon the invitation
- KMail sends the ical and the user decision to KOrganizer that returns
a new ical with the answer
- KMail stores the appointment directly in the Calendar folder
The new way it's going to be:
- KMail receives a mail with an invitation
- KOrganizer (or libkcal or whatever) decodes the ical file and shows
a widget with the choices inside KMail
- The decision goes to KOrganizer and KMail doesn't see it again
This way it's up to KOrganizer what to do with the saving of the file.
This is necessary to make use of KOrganizers resource settings. And it
also makes it possible to use KMails groupware stuff without saving the
calendar files inside KMail. In case KOrganizer uses the IMAP resource,
the file will actually go back to KMail, but that is through another
channel of code.
This checkin is the first part of making the groupware code and the
IMAP resource code in KMail be quite independent of each other as it's
supposed to be. In kroupware_branch all this code is completely tangled
up in one big web. The untangling isn't completely done yet, since I by
now have been in the process of doing this transition for 7-8 weeks, and
I wanted to get it off my disk.
I'm certain that IMAP resource doesn't work right now, but I'll fix this
over the next couple of days. After that, we should finally be almost
done with the KMail work, and I can concentrate on getting the groupware
parts in KOrganizer ported.
CCMAIL: kmail@kde.org
CCMAIL: kdepim@kde.org
svn path=/trunk/kdepim/; revision=225393
Till Adam
Bo Thorsen
David Faure
Andrew Coles
Laurent Montel
Cornelius Schumacher
Ingo Klcker
Marc Mutz
Shaheed Haque
Stephan Binner
Zack Rusin