Thu 08 Aug 2013 05:01:42 PM UTC, original submission:
This isn't so much a bug as it is finding the desired behavior.
If the history always scrolls when a command is issued, the history window has the undesirable property of moving when double-clicking some command far back in the history list when the user probably wants to remain in place and possibly use other nearby commands at that point in history.
If the history never scrolls then at start up its as though history is not being updated.
The attached patch is meant to strike a balance. If the user ever intentionally scrolls away from the most recent history, the history will not scroll to bottom with a new command. If the user moves the slider back to the bottom, then it will scroll again with new commands. That is the general idea. The algorithm is to scroll if max - value < 5. Not 5%, but 5. It seems to be fairly good as an initial start, but there might be similar algorithms.
Can either apply this and see what the response is, or hold off for a bit and see if there isn't something better. The one dodgy area might be if the user wants to get at commands that are just beyond the upper edge of the history window, i.e., "fairly recent" history and the window keeps scrolling back pushing the desired commands just off the edge of the window. Since the user is more apt to use fairly history, this might be common.
Could make it an exact bottom, i.e., if max - value < 1, but I'm wondering if users will find that too stringent. I'll experiment.
|