Mark message read after displaying for X seconds - idea for timing improvement near zero seconds.

The setting, “Mark message read after displaying for X seconds”, has a setting for 0 seconds.  However, from the time I click on the item, it usually takes 1 to 3 seconds for the item to be marked as read.  I would prefer that clicking on an item marked it immediately, but there seems to be no such option.  I can imagine several solutions.  Perhaps others have solutions consistent with modern browsers?

Add a new item, “Mark message read when selecting it.”

The reason that this is important is that, for me and for clients that I am used to, it is the act of selecting the item that determines that it should be marked, not the actual reading of the message.

Jörg Giencke wrote 2 comments that did not appear in this forum:

“I’ve checked that in eMC 7 and 0 seconds marks read almost immedeately (< 0.5 seconds). If it does not it’s most likely be due to slow server communication because marking is done on the server and the client has to wait for a confirmation.”

“How do you read a message without selecting it?”

The semantics of the setting,  “Mark message read after displaying for X seconds”, suggests that eM Client displays the message before marking the message as read. After the message is displayed in the preview panel, the item is selected almost immediately.  This is consistent with the semantics of the setting.  My experience in using this client is that I have to pause for the preview to load before selecting another item.  If I select another item too quickly, the first item I clicked on never is marked as read.  This slows down my work, and why I suggest that the item be marked as read when I click on it regardless of how quickly I click on something else.

You can read a message without selecting it from the list in the main eM Client window if, for example, you click on a Windows notice box.  There may be other ways that I am not aware.  My suggestion applies in response to clicking in the list, not in response to viewing the email message.  From a programmers perspective (I am one), the first action of the event handler for the clicking on an item in the list should be to mark it as read, if the suggested setting is set.

BTW, I am using a stand-alone application on MS Windows 7.  I was not aware that it was implemented as a client-server architecture.  

Thanks for asking.  

“I was not aware that it was implemented as a client-server architecture.”

Using IMAP it has to. Client and server have to be kept consistent.

I deleted my comment because I wasn’t sure anymore how it’s implemented in eMC 7. The safe and straightforward way is to ask the server to mark, wait for a response and mirror the result in the client. That always causes delays.

The ‘quick reponse way’ is to mark in the client and simultaneously ask the server to mark as well, hoping that it’ll work. If not you have to roll back what you did in the client - more code.

That’s what’s going back and forth between client and server:

09:34:38.519|00E|   A45 UID STORE 15001 +FLAGS.SILENT (\Flagged)
09:34:38.549|01E|   * 4 FETCH (UID 15001 MODSEQ (2209))
09:34:38.549|01E|   A45 OK Store completed (0.000 secs).

I see the design.  However, it is possible to work offline with this email client and synchronize with the server later.  So the “quick response way” is fine provided that synchronization includes the read mark, which it normally does.

Your explanation does not account for why the item selected is never marked as read if the user quickly selects another item in the list.  But the semantics of the setting does agree with the program’s behavior.

I tested online and offline and it works the same, and as expected.  There is a difference in delay depending if the message was already loaded from server to client.  The offline test was to mark an item as unread and then mark it as read.  After connecting the Internet again, the synchronization is propagated to the email server via IMAP as expected.  If I click on an unread item and quickly click on another item, the first item remains marked as unread.  The behavior  we have been discussing is independent of the connection with the Internet and email sever.

Are you close to the development group?  If so, give them my compliments.  Aside from this annoyance, this is a very nice email client.

“Your explanation does not account for why the item selected is never marked as read if the user quickly selects another item in the list.”

If you scroll down the list too quickly the ItemSelectionChanged event might not get fired for every list item. ItemSelectionChanged is one of the (or the) last event(s) in the long row of events that get fired when you select an item - with other events having priority. If you’re already somewhere else the system will not fire it - because it’s not true. There’s hardly anything one can do about it.

I’d do Crtl + A and Ctrl + Q.