#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
Bo Thorsen
Stephan Binner
Ingo Klcker
Zack Rusin
Stephan Kulow
Melchior Franz
Carsten Pfeiffer
Matthias Kretz
Daniel Molkentin
David Faure
Marc Mutz