Enhance list and toolbar usability

Originally posted by: tortoisesvn

Changing issue type to "Enhancement".

* Implementing Ctrl-A will be easy to do.
* The context menus for "Mark as read" - what would that be good for? If you click on
the revision, it is automatically marked as read. But "Mark as unread" could be done
- even though I don't see the point why.
* Making the tooltips dynamic depending on what is selected can be done, but won't be
as easy as the points above
* using SQLite could be done too, but the aim of the whole project is to only monitor
for new commits, nothing more. And to do that, it has to run always - which means its
memory footprint must be kept as small as possible. Adding something like SQLite just
for storing the data would be against that goal.

Labels: -Type-Defect Type-Enhancement

Originally posted by: rene.leonhardt@gmail.com

"Mark as read" would be useful, if the selection implementation would not
automatically mark all selected items as read, without having them displayed even once.

Mark as unread would be nice, if the user wants to reread a long revision log message
at a later time (and because selecting or displaying list items marks them as read
automatically).

The SQLite DLL is very small and therefore should not be larger in memory than a few
100 KB and it would open up lots of possibilities for future enhancements.
If it would be much too big, it could be unloaded when the Window looses the focus.

A GUI form element for the now implicit option to retrieve only a maximum number of
last revisions (it seems to be 10 at the moment).

Originally posted by: tortoisesvn

Marking a log entry as read when it is selected won't change, so "Mark as read" isn't
really that useful.

You said that "Mark as unread" could be used to reread a long message again - but you
can do the same without that: just select the message again.
Since this tool is for monitoring *new* commits only, I don't like the idea of
implementing something to fetch old log messages again once they're removed. For
that, you should use your Subversion client and the 'svn log' command (e.g., the log
dialog in TSVN).

Yes, the SQLite dll is small. But that's just the dll - it takes a lot more than its
size in memory. Right now, the memory footprint of the CommitMonitor is around 1MB
when idle - with SQLite, it would be a *lot* more than just that.

The maximum number of last revisions as you mentioned is in fact set to 10. But
that's only for new projects. Since the tool is for monitoring *new* commits, that's
more than enough. If however there are more than 10 new commits between checks, it
will show *all* of the new commits, even if there are hundreds of them - but I guess
that would only happen if you would forget to start the tool for a month or so,
depending of the monitored project.

Originally posted by: tortoisesvn

Starting (implementing Ctrl-A - the rest of the request is not useful).

Owner: tortoisesvn
Status: Started

Originally posted by: tortoisesvn

Done in [r244].

Status: Fixed

Originally posted by: tortoisesvn

(No comment was entered for this change.)

Status: Verified