ConfigModule (from configuredialog.*) as the base class.
This will make it possible to add a 3rd optional tab for ACLs.
This could also allow implementing an Apply button, but for this the code
for save() (was: slotOk) must be ready to be called multiple times, which I
guess isn't the case when creating a new folder.
svn path=/trunk/kdepim/; revision=301784
This reduces the signal storms and cpu spikes as well as the flicker which
are especially noticable over slower links. Seems quite a bit smoother now
here.
svn path=/trunk/kdepim/; revision=298121
- add storage property "noChildren" (guess what it does)
- allow the creation of subfolders of system folders (except the outbox)
- the content of the belongs-to combox in the folderdialog looks like the foldertree
- get rid of old stuff in kmfoldertree
- kmfoldertree is the parent of kmfolderdialog
...and fix the mailinglist handling
CCMAIL: 11903-done@bugs.kde.org
CCMAIL: 37139-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=295688
Implementing automagic mailing list handling: KMail can now detect whether
a folder stores a mailing list in which case it will try to determine its post,
subscribe, unsubscribe, archive and help addresses.
Aaron could you figure out where the kaction's invoking post,subscribe... could
be put?
CCMAIL: aseigo@kde.org
svn path=/trunk/kdepim/; revision=295216
test bed. After a short discussion with Marc on irc I've decided to call
the global class GlobalSettings, as we expect there to be at least
ComposerSettings and ReaderSettings in the not too distant future.
If no one yells, I'll be amusing myself by moving stuff over to the new
style section by section over the next few millenia. If anyone wants to
help please tell me, so we can coordinate.
svn path=/trunk/kdepim/; revision=289835
the base class method KFolderTree::contentsMouseReleaseEvent.
This is because KFolderTree::contentsMousePressEvent changes the
selectionMode of the listview to single, and KFolderTree assumes that
a complementary call to contentsMouseReleaseEvent is made to change
the selectionMode back to being extended.
This fixes the problem with Ctrl-Left/Right navigation of the foldertree
listview changing the selectedItem as well as the currentItem. The problem
being that after a folder was selected with the mouse the selection mode
was stuck in single mode.
svn path=/trunk/kdepim/; revision=283213
Don't try to decrypt anything while a popup menu is shown.
The real fix is making the decryption non-blocking. But that'll have to wait till after KDE 3.2.
CCMAIL: 56693-fixed@bugs.kde.org
svn path=/trunk/kdepim/; revision=270269
and bug 69230: different problems regarding searching / virtual folders
It's actually the same bug and it was introduced by a recent patch which was reviewed by two (!) persons. The next time you review something please actually test the patch and don't just say "Hmm, looks good.". Yes, I'm guilty of the same lazyness. Let's make sure it doesn't happen again.
CCMAIL: kmail@kde.org
CCMAIL: 69176-fixed@bugs.kde.org
CCMAIL: 69230-fixed@bugs.kde.org
svn path=/trunk/kdepim/; revision=270255
folder showing up as selected in the folder listview and another set of
messages showing up in the message list (if you click on one folder and
release on another).
CCMAIL:68694-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=269493
foldertree can select the local folders to avoid crashes when a folder
and a mail from the removed account is currently selected and being
displayed.
Should be improved eventually to only do it if the current account is
the removed one, but I didn't see an immediate way to do that.
CCMAIL: 66875-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=263243
by popular request and add it to the Folder menu. Disable it there for non-
imap folders.
CCMAIL: 66123-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=259435
#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
prevent crashes when it fails due to the user cancelling the password
dialog and the slot being called again in the meantime and messing with
the folder tree item still in use by the other incarnation of the slot.
Coolo, can you confirm this fixes it?
svn path=/trunk/kdepim/; revision=251977
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
1) Remove the limitation that a message can have only one status at a time.
2) Implement watch/ignore thread via message status flags.
ad 1:
- Message status is now kept as a bitfield, which means a message can now be
for example replied and forwarded as well as important at the same time.
- To keep the index format backward compatible and make the transition
painless, I've added a new index entry and added code to transfer the old
into the new format. That means that upgrading users should not notice
anything.
- I've tried to keep as much behavior as possible unchanged with regard to
what flag disables what other flag etc. There are two groups of flags:
read/unread/new/old influence each other, which means a message cannot be
new and read at the same time, for example, while the second group, namely
important, sent, queued, replied, and forwarded are toggled individually.
- Toggling a thread sets the messages status to the inverse of that of the
parent, which means that if you have a thread with some mails marked as
important and some not, the status is set according to that of the parent.
- Status is now kept when moving mails between folders in the same imap
account as well as between imap accounts.
ad 2:
- Watch and ignore are mutually exclusive, which means ignoring a thread
unsets its watched flag and the other way around.
- When sorting by status watched threads are at the top, ignored at the
bottom.
- Watch and ignore propagate via threading, which means that if a message
is threaded below a watched one, it becomes watched. Same for ignore.
- Moving a single mail out of a watched thread results in a new watched
thread of size 1 :)
- Similarly watch and ignore are possible on individual mail (threads
to be).
- Watching a thread does not currently mark new mails as important, nor
does ignoring delete new mails in the thread. These are possible
extensions, though, if we think them sensible.
svn path=/trunk/kdepim/; revision=235595