Version: (using KDE 4.2.0) OS: Linux Installed from: Fedora RPMs When a thread is deleted (CTRL+DEL), one expects the next selected message would be the first after the deleted thread. However, in KDE 4.2's KMail, more often than not the selected message will be a random one after the deleted thread. I think that if a thread with n messages is deleleted, KMail skips the next n messages and selects the next one. However, it seems that if this skip places the selection marker inside another thread, then an apparently random message is selected. I'm not sure that this is exactly what happens, all I know for sure is that very often the message that will be selected when a thread is deleted is not the first message after the deleted thread.
Confirmed in kmail 1.11.90 (kde 4.2.62).
*** Bug 187031 has been marked as a duplicate of this bug. ***
I might not be 100% random. Here's what I noticed just now. I had a thread with 3 emails: Wednesday 00:06 Wednesday 07:38 Today 1:46 (Today is Friday). After deleting this entire thread with "Ctrl-Del", KMail selected email dated Wednesday 3:41. It appears to be the closed email in time to "Wednesday 07:38", so it almost looks like KMail picked a wrong email in the deleted thread, and selected another email close to that wrong one. Can anybody point me at the code responsible for selecting next email?
Nevermind, it appears to be KMail::MessageListView::Core::View::messageItemAfter. I shall look into that.
SVN commit 978730 by stefanek: A new approach to the choice of the next message to select in place of the ones being deleted. BUG: 195531 BUG: 187297 BUG: 183923 M +3 -0 core/model.cpp M +180 -13 core/view.cpp M +1 -0 pane.cpp M +2 -1 widget.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=978730
It appears the next message is now selected accurately -- thanks a lot! However, it seems like this patch introduced a small glitch. If I delete a thread, using Ctrl-Del, everything is fine -- next email is selected and displayed. However, I have a single email selected, and delete it using Del, then next email is properly selected, but not fetched. The progress bar does not show any attempt to fetch the newly selected message. Not that if I have selected a single message, and delete it with Ctrl-Del, then everything works fine, so I presume that "Delete a single message" code path just accidentally fails to trigger message fetch.
I have another question. Say I use "current activity, threaded" aggreration. I have "yesterday", "last week" and "may" headers, with "last week" collapsed and two others expanded. If I select the last thread in "yesterday" and delete it, the first thread in "may" is selected. I would have expected the first thread in "last week" to be selected, with "last week" auto-expanded as result. Can this probably be a configuration option?
Indeed, when deleting a message, the next one is not fetched anymore. Szymon, can you have a look at this regression please?
SVN commit 979514 by stefanek: Fix a regression introduced with the yesterday's commit: _first_ need to call setCurrentIndex() and _then_ select(). Now it seems ok. BUG: 183923 M +2 -3 view.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=979514
Vladimir: the second request is questionable. People might want or not want this behaviour. This could be made configurable but I'd say that we need some votes for the option to be added: AFAIK the developers generally frown upon options added to the configuration dialog without a sufficient number of requests. I'd say: open a bug/wish and let people vote it (or just jump into #kontact on freenode and convince a couple of folks in there :D)
I can confirm "Delete" now works properly. Thanks! As for selecting messages inside closed groups, I realize that adding options is not always best. I'll try to use this version for a week before filing an enhancement request -- it possible that easy way to collapse/expand agregation groups is alternative approach.
*** Bug 196372 has been marked as a duplicate of this bug. ***
*** Bug 197112 has been marked as a duplicate of this bug. ***