RE: Bug report: Project Monitor automatically marks items as read

Thanks for your response.

> Yes. But in the project monitor, you don't have to tab first to the log view pane or click. Instead you can right away hit the cursor keys to browse through the log messages.

I don't understand how that helps. The newest item in the log message window is always automatically selected as soon as I select a project. Example:
- PM notifies me that a project has 2 new commits
- I open the PM window
- Project is highlighted in the project list and shows (2) new commits. The log message window remains empty until I select a project in the project list.
- I click on the project in the project list
- The newest commit in he project is automatically selected and marked as read.
- The project list now shows only (1) new commit.

> It's different, yes. But I think project monitor handles this better for most users. You have no idea how many emails I got from users of CommitMonitor because they're confused about why the messages are kept as unread even though they 'read' it: reading for them means glancing at the overview, not having to select each revision individually.

I guess it depends on what your interpretation of the word 'read'. In the current implementation of PM, items are considered 'read' once they have been displayed to the user, but it is not consistent in this approach. The newest commit is considered 'read' as soon as it is displayed. Other new commits in the same project are not considered 'read' until selected by the user, or until the user exits the project view then they are all considered 'read'.

For consistency, all commits should be consistently marked as read as soon as they are displayed in the log message window, or none of them should be. The newest commit should not be a special case. I think an easy solution would be to NOT automatically select the newest commit in the log message window. That would allow all new commits to remain 'unread' until the user explicitly selects them in the log message window, or closes the PM window, or selects a different project.

With that said, I still think there is a use case for retaining the 'unread' status until the user explicitly selects an item or otherwise explicitly marks it as read (similar to what Commit Monitor does). Maybe this could become a user selectable option?

Consider Outlook, or almost any other email client, as a counter example to the current PM operation. Email messages are not marked as 'read' just because the list of messages was shown to the user. The user must explicitly select a message and display the contents before the message is marked as read. Messages are never automatically marked as read, regardless of whether you select a different folder, close the program, etc. I think this is a very common and well understood model, so I don't understand why anyone would be confused by it. I believe Commit Monitor works in a similar way?

Obviously the "email-style" approach to marking things as 'read' is what I would prefer. My perspective is biased by the fact that I am a manager, so usually want to review all new commits, and I don't want any of them to get automagically marked as 'read'.

I hope this makes sense and is constructive. Thanks!

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3142245

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2015-10-14 19:55:01 CEST