active readerwindow to ask that for the attachmentstrategy but pass it
along with the folder job, so it is available when the mime structure
comes in with load on demand. Remove unused KMKernel::activeReaderWindow
which doesn't work in kontact anyhow.
CCMAIL: 67644-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=268877
This should fix a bug with ad hoc filters crashing when they move a message
to a different folder.
And also fix the bug/limitation that the move to folder action has to
come last in the list of filter actions for a filter.
This commit doesn't really use the action scheduler, code to use the
action scheduler in kmheaders and kmcommands is commented out.
I've been testing this code for a few weeks now. The changes to the
assignment operators in the kmmessage and kmmsgbase classes are the
changes I'm most concerned about here.
svn path=/trunk/kdepim/; revision=264912
signals from being emitted.
This should fix the sent folder count updating bug. If it does not for
you, please reopen.
Patch Ok'ed by Till (Don also agreed that quiet() can be removed).
CCMAIL: 63670-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=260199
result in the creation of a folder named "", the deletion of which inspires
kmail to remove all of ~/Mail.
Reformat the code somewhat according to the pim style in an attempt to maybe
figure out what it does and make it suck less. Give up on that for fear of
breaking random stuff.
CCMAIL: 60575-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=260195
account associated with it yet. This can happen when you create a new imap
folder and then click on it before the server has finished acknowledging
its existance.
svn path=/trunk/kdepim/; revision=254002
This of course leaves that file without a license, sure it's a violation of
KDE policies but because radej and dijkema who are listed in the files annotate
are no longer with us, there's no way to consult license of that file with them.
Now here's a question:
does the fact that KMail is GPL mean that this file is GPL or does the fact
the this file doesn't have a license mean that KMail doesn't have one?
svn path=/trunk/kdepim/; revision=252760
#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
main readerwindow but there is a restored composer which has focus so that
KMKernel::activeReaderWin() returns ... nothing useable.
Is there a way to make it return the correct reader window? That would be
preferrable, of course.
svn path=/trunk/kdepim/; revision=251973
2) Hi, I'm a cpp file that includes everything he can.
3) Hi, I'm a file without a license.
4) Hi, I'm Zack and I have a problem with #1, #2 and #3.
svn path=/trunk/kdepim/; revision=250436
Save window settings as in konq_main but factor MainWin closing into kernel.
Modify KmComposeWin::setMsg to add an argument to specified that mails are modif
ied, this is to prevent losing mail when deadletter composer mails are restored.
Add a kernel method to signify when KMail is in a shutting down state as in the
case of session management.
Modify the queryclose methods so that they don't query when session management i
s being used or when Kontact is being used.
Move the queryClose warn-on-expiry logic from KMMainWidget to KMMainWIn so that
it actually gets called.
svn path=/trunk/kdepim/; revision=245342
Especially protocol() == "imap". Note that using ssl completely breaks those
checks then as the protocol is then "imaps". Also the string compares
are suboptimal there - use folderType() == KMFolderTypeSomeType.
svn path=/trunk/kdepim/; revision=238868
because it is used as a part, for example. Since mainWin is only used
as a parent for message boxes, this should be no problem.
svn path=/trunk/kdepim/; revision=232198
KMail::UndoStack.
Waldo, would you mind if I added the Qt clause which we discussed some time ago
on the KMail list to the undostack.{h,cpp} files?
CCMAIL: Waldo Bastian <bastian@kde.org>
svn path=/trunk/kdepim/; revision=227174
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
To Sven: follow the style of the file to which you are committing.
To all others: removing printf's and switching some asserts.
To myself: you got a nice butt.
svn path=/trunk/kdepim/; revision=223697
Till Adam
Ingo Klcker
Don Sanders
Stephan Binner
Bo Thorsen
Roberto Teixeira
Stephan Kulow
Ladislav Strojil
Marc Mutz
Zack Rusin
Carsten Burghardt
Laurent Montel
Helge Deller
George Staikos