(better than <foo.h>, especially when systems could have an identity.h somewhere)
A kconfig_update script moves the identities from kmailrc to emailidentities
svn path=/trunk/kdepim/; revision=311347
mail syncs and use KMAccount::checkingMail() which is the generic tool
for the job instead. We need to make sure that all invocations of
processNewMail are guarded, and that all error paths reset it. Since we
are currently in the process of making error handling a bit less chaotic,
we'll hopefully achieve that.
svn path=/trunk/kdepim/; revision=306085
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
- Moves the wizard running code to the startup of KMail, so the
wizard is run before KMail starts
- Fixes a number of crude hacks in the groupware configuration
- Makes the wizard more usable as a general wizard instead of
just a groupware wizard
svn path=/trunk/kdepim/; revision=217242
David Faure
Till Adam
Andrew Coles
Jonathan Riddell
Ingo Klcker
Laurent Montel
Marc Mutz
Bo Thorsen
Stephan Binner
Zack Rusin
Stephan Kulow
Melchior Franz
Carsten Pfeiffer
Matthias Kretz
Daniel Molkentin