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
has it's own cursor stack.
I added kcursorsaver, that makes sure that the cursor is restored when the object
gets out of scope (just as KConfigGroupSaver)
Now kmkernel doesn't has to cope with cursors anymore
svn path=/trunk/kdepim/; revision=221747
Till Adam
David Faure
Bo Thorsen
Andrew Coles
Laurent Montel
Cornelius Schumacher
Ingo Klcker
Marc Mutz
Shaheed Haque
Stephan Binner
Zack Rusin
Stephan Kulow
Steffen Hansen
Matthias Kretz