| Summary: | Kmail delete message no longer centers next selected message in message list | ||
|---|---|---|---|
| Product: | [Applications] kmail2 | Reporter: | Geert Janssens <info> |
| Component: | message list | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | bjoern, kde, mmtsales, pete, qiilaq69 |
| Priority: | NOR | ||
| Version: | 5.4.3 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Geert Janssens
2009-12-27 18:35:15 UTC
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. |