The MessageWidget should stop showing the current message when that message disappears. The user cannot really use that widget for interacting with the message's content apart from what is already loaded and visible on-screen. One cannot really even reply to it, for example. On the other hand, the fact that the message remains visible is nice because it covers up the full model reset on reconnect, so that it's possible to e.g. continue reading a message even after reconnecting, etc. (Received by private mail from transvirtual@hushmail.com)
> the fact that the message remains visible is nice That. I sometimes even delete & expunge before having completely finished reading the mail ;-) => "Hint" that it's gone, but keep the text in sight? (But diabling would make select+copy impossible, so it needs to be something different)
This behavior is unintuitive. If you need access to a message which is no longer in the "active folder list" then it would make sense to require navigation to the location of that message (i.e. trash). This state also prevents the next/previous actions (shortcuts and menu items) from functioning. The question is, what to you do if you don't display the message anymore? Does the MessageWidget collapse? Does it show the next message? If it shows the message, do you mark that message as read? My desired behavior is to show the next message and give me an option of marking it as read (but not automatically marking it as read). Minimum requirement: Still allow next/previous message actions to function.
> This behavior is unintuitive. Agreed. > If you need access to a message which is no > longer in the "active folder list" then it would make sense to require > navigation to the location of that message (i.e. trash). That also makes sense. Note that this message might very well be gone for once and not available at all (once it gets expunged from its mailbox). > This state also prevents the next/previous actions (shortcuts and menu > items) from functioning. That's bad, but at least there's https://gerrit.vesnicky.cesnet.cz/r/896 for that. > The question is, what to you do if you don't display the message anymore? > Does the MessageWidget collapse? Does it show the next message? If it shows > the message, do you mark that message as read? > > My desired behavior is to show the next message and give me an option of > marking it as read (but not automatically marking it as read). What you mean by "give me an option of marking it as read"? Do you mean just moving to the next message as usual without starting the timer which marks it as read, and still allowing all operations such as replying, deleting, or marking as read by an appropriate button/shortcut?
Git commit 7179c38fbff9c5e881112e381731bdc29b0530d5 by Jan Kundrát, on behalf of Roland Pallai. Committed on 21/04/2017 at 20:05. Pushed by gerrit into branch 'master'. Move cursor to the next message after current one disappears A big inconvience for keyboard usability if the cursor forgets last position when the current message disappeared from message list. It also prevents next/previous message actions to function. This patch using an unobtrusive approach to this problem, moves the cursor to the next message but does not activate it. The user can activate with return key or can navigate towards. This way it does not interfere with automatic read marking nor habits of users. Related: bug 321387 Change-Id: Ic823c2c9d0bba9de65d01fb0e72b91093f233f7e M +66 -0 src/Gui/MsgListView.cpp M +6 -0 src/Gui/MsgListView.h https://commits.kde.org/trojita/7179c38fbff9c5e881112e381731bdc29b0530d5
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!