Version: (using KDE 4.3.3) OS: Linux Installed from: Fedora RPMs Description of problem: The message list in kmail shows a number of e-mail headers. When navigating this list with the keyboard (arrow-left and arrow-right), kmail always keeps the selected message at the centre of this list. This way, you can easily see which messages precede it in the list and which messages follow it. Kmail in 4.2.x did the same thing when you deleted a mail. The next selected mail would end up in the middle of the message list. This no longer happens in 4.3.2 and 4.3.3. To be clear: the next message is still automatically selected, but it is no longer placed in the middle of the message list. So with each deletion, you see one preceding message more and one following message less. After a few deletions, the selected message will be the last visible one in the list, so you don't see the following messages anymore. This is not a serious bug, but is usability regression. Steps to Reproduce: 1. Start kmail 2. Select a mailbox with a lot of messages (which you can delete) 3. Scroll the message list to somewhere in the middle, and click on a message there. 4. Now press the delete key => Observe that the message gets deleted, and the following message is activated, but also that this newly activated message is not moved up to be in the centre of the message list. 5. Press the right arrow key to activate the next message. => Observe that the next message is activated and that it is moved up to be centered in the message list, so you can see multiple message above and below it. Obvious workaround: Use the scrollbars or arrow keys to re-centre the message. This works but is interrupting a fluid workflow.
I confirm this - it does make working through a large number of messages rather awkward. Should be a straightforward fix, I hope? :-)
I find it annoying that kmail is always shifting the message list to keep the selected line in the center. Not only is it more difficult to keep my bearings than if the message list is stationary, but the shifting is not smooth and it slows down the window update. Message display is already slowed down enough, compared to a few versions ago. So rather than see the above behavior as a bug, I would like to see it as an option.
(In reply to comment #2) > I find it annoying that kmail is always shifting the message list to keep the > selected line in the center. Not only is it more difficult to keep my bearings > than if the message list is stationary, but the shifting is not smooth and it > slows down the window update. Message display is already slowed down enough, > compared to a few versions ago. So rather than see the above behavior as a > bug, I would like to see it as an option. My explanation seems to be confusing. From your reaction I understand it's not necessarily "centering" I require, but that visually the selected message remains in the same spot. I have quickly tested the behaviour of other mail clients (Thunderbird, Evolution). All of them make sure the selection is not moved after a delete. Let my try to describe the visual behaviour I'm missing a bit better using an example. Suppose I have a mailbox with many message in it. The message list is sized such that I only see 8 message headers at the time. At some point, the 4th message in this list is selected (highlighted in blue or whatever you have as higlighting colour). I don't want that message anymore, so I hit the delete button. What should happen now: * The highlight remains on the fourth visible message (in other words, the blue highlight doesn't move at all) * The message just below the one I just deleted, moves up, into the highlighted area, and thus becomes the new selected message. * All the messages below this one just move up the list as well. If more messages were selected before hitting the delete button: * The highlight is reduced again to one message. If the beginning of the original selection was visible, this one message selection should be the first message that was originally selected (so again the highlight itself doesn't really move, just reduces in size again). If the start of the selection was not visible, I would prefer it to become visible, otherwise I would have to search the message list again to find out where I was. * The first message below the deleted ones moves up into the single line highlight. All messages below move up the list as well. It's written down a bit cumbersome and backwards, but I wanted to stress the idea that the message highlight is the most important visual clue the user has in the message list and this should move a little as possible when deleting messages. On the other hand, I think what comment #2 refers to is the visual effect you get when you delete many messages at once. Kmail seems to iterate through the messages one by one, and with each removal update the message list (which each time triggers the move-messages-up-the-list animation). This does indeed cause an unnecessary delay, but for me this is another issue altogether (and perhaps should be reported in a different bug). This issue is really about the highlighted area itself moving down after each delete and has nothing to do with the animations.
The window is updated anyway but the point of the bug report is that it should be updated so the selected mail doesn't move and updating is "from below" - contrary to the present behaviour when updating is "from above".
This problem still affects kdepim-4.7.3-1.fc16.i686 on Fedora 16
This may be the same bug reported in #198188 and #236987
I looked at the other two bug report. They describe exactly what I meant as well. So I think these are duplicates. I'm not sure which bug should be considered the original. The oldest one ? Or the one with most comments ?
Thank you for taking the time to file a bug report. KMail2 was released in 2011, and the entire code base went through significant changes. We are currently in the process of porting to Qt5 and KF5. It is unlikely that these bugs are still valid in KMail2. We welcome you to try out KMail 2 with the KDE 4.14 release and give your feedback.
It is unlikely to be valid in the Qt5 port or in the current version? It is still valid in 4.14.1 (Kubuntu packages) and I don't think this is something that will get fixed only by porting the code to Qt5.
This bug has never been confirmed for a KDE PIM version that is based on KDE Frameworks (5.x). Those versions differ significantly from the old 4.x series. Therefore, I plan to close it in around two or three months. In the meantime, it is set to WAITINGFORINFO to give reporters the oportunity to check if it is still valid. As soon as someone confirms it for a recent version (at least 5.1, ideally even more recent), I'll gladly reopen it. Please understand that we lack the manpower to triage bugs reported for versions almost two years beyond their end of life.
Kmail 5.4.3 and this issue is still happening for me.