messages from the headers list (move/delete operations) works to:
o figure out what message to select afterwards (the one below or above the
selected ones or none at all if all are being deleted)
o mark all selected messages as aboutToBeDeleted and non-selectable
o select the previously remembered message
o kick off the move action during which the aboutToBeDeleted messages remain
unselectable
That means it should now be impossible to select a message that is going
away or change a KMMsgBase pointer to a KMMessage pointer thereby
invalidating the list of messages currently being moved.
svn path=/trunk/kdepim/; revision=253428
command up to the target folder's msgAdded signals and ticking off each
serial number as it comes in. To make that possible, use the metaDataMap
for imap folders to restore serial numbers after the move (along with
status). Also connect to the folderCompleted(bool) signal of imap folders
to make sure we notice if not all messages make it to the other side.
Connect kmheaders to the abortRequested signal and make sure cancelling
moves behaves somewhat more gracefully and restores the state of messages
remaining in the folder, making them selectable and setting their transfer
status to false so they can be downloaded or moved again.
svn path=/trunk/kdepim/; revision=252676
#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
rely on the MoveCommand to find a message to select that is not one of
the ones being moved. Prevents a crash with moves between folders on the
same account. Also make sure non-selectable items are not selected when
something other than QListView does the selecting.
svn path=/trunk/kdepim/; revision=252310
example to the trash) unselectable and paint a line through them, to
visually indicate that they are going away. This is especially noticable
in imap folders where the messages are removed one by one as they arrive
in the destination folder.
svn path=/trunk/kdepim/; revision=250967
command needed to know about the headers to figure out what message to
select once the move is done, but that can and should imho be done in the
headers themselves. There was a ToDo to that effect in there, so I guess
the original author agrees. :)
svn path=/trunk/kdepim/; revision=249824
list as before or to the right of it or hide it completely. When the reader
window is disabled, messages that are selected are not downloaded (for
imap) and are not marked as read.
CCMAIL: 63647-done@bugs.kde.org
CCMAIL: 16345-done@bugs.kde.org
CCMAIL: 43176-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=249504
Imap job folder ref counting should make manual ref counting previously used obsolete.
Is probably better to wait for global filter manager cleanup rather than calling it here.
svn path=/trunk/kdepim/; revision=245378
zation working around a qlistview bug the disappearance of which caused
the simple way of doing it to be much more efficient. So we do that now.
svn path=/trunk/kdepim/; revision=245359
level items (thread parents) newest on top but sort the messages inside
the thread by descending date. I am told people want to have the newest
threads on top but read the threads top to bottom, so it makes sense
to sort the thread different from the parent.
o speed up re-sorting in the current folder (by clicking on the column
headers) by implementing a custom compare function and making sure the
date and size fields are unique by appending the serial number of the
message. This prevents qlistview from looking at the next column to
decide preference and do expensive localeAwareCompare()'s
o additionally speed up sorting by not using localeAwareCompare() for dates
and sizes
svn path=/trunk/kdepim/; revision=245307
that message does not have to be reevaluated in the future
o write the discovered count to the right offset in the .sorted file
o increment sorted_count in the .sorted file, as we now thread arriving
messages immediately instead of on the next folder open
o rename appendUnsortedItem to appendItemToSortFile to reflect that
svn path=/trunk/kdepim/; revision=241710
because the wrong item is removed from the sort cache item dict and the
one that should have been removed is later referenced.
CCMAIL: 58305-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=241643
change threading to a two pass strategy which first finds parents by
headers, and afterwards builds lista of possible parents for subject
threading out of all messages that are top level after the first pass.
Then use those for finding subject parents. That's the only way I see
to avoid nasty circularities with messages _older_ than their parents
arriving out of order, while still keeping date affinity of subject
threading. (urghs)
svn path=/trunk/kdepim/; revision=241501
o Keep around the KMSortCacheItem based structures that are created in
readSortOrder and update them in msgAdded and msgRemoved instead of
building new structures based on KMHeaderItems. This requires keeping a
pointer to the corresponding KMSortCacheItem in the KMHeaderItems and
vice versa (as before). Slight memory overhead, increased performance
on folder open.
o As a result of this, get rid of duplication of the threading logic and
consilidate that into a separate findParent() method which is used both
by readSortOrder and when reparenting in msgAdded/msgRemoved.
o Factor out building of the threading dicts into a separate method.
o Instead of keeping only one potential parent for subject threading for
each subject keep all of them in a list sorted by date.
o Subject thread messages under the potential parent that is closest by
date.
o Don't subject thread under potential parents more than 6 weeks older than
the current message.
svn path=/trunk/kdepim/; revision=240784
encrypted. The subjects don't line up anymore anyhow now that multiple
status icons are possible. Ingo and Don are fine with this, Carsten, Marc,
Zack, ok with you?
svn path=/trunk/kdepim/; revision=240778
menu is shown, but when the folder/message changes. That way the actions
work as expected when they are put on the toolbar, for example. For
messages, this was already partly done, and the updates are triggered via
a timeout, so that quickly passing over messages is less expensive. For
changing folders, I don't think that is necessary.
o Remove aboutToShow menus -> update menus hooks in kmmainwin.cpp.
o Add the watch thread and ignore thread actions to the main Folder menu.
Bump .rc file version number.
o Consolidate the enable/disable logic for the status actions in
kmmainwidget.cpp and remove it from kmheaders.cpp.
svn path=/trunk/kdepim/; revision=238612
KToggleActions for those stati that are toggleable.
If toggleable is not an actual existing word, it should be. So there.
svn path=/trunk/kdepim/; revision=237681
- dito for the automatic mark as read timeout in kmreaderwin
- propagate mark as read in ignored threads to the server for imap folders
svn path=/trunk/kdepim/; revision=237665
mail notification for mail in ignored threads as a side effect. I strongly
suspect this is the desired behavior.
svn path=/trunk/kdepim/; revision=236026