gitk next/prev buttons

The "next" and "prev" buttons are lacking consistency and logic. For RTL languages previous is almost always on the left, and next on the right. The words are contradictory, "next" actually goes to backwards chronologically, and "prev" goes forward. Could the positions of the buttons be switched and the text be replaced with "earlier" and "later"? This would make the reference time not just order, and would mean the updated UI would not be confused with the previous one.

Also, the arrow-only next/previous buttons (beside the commit ID) should really point up and down. Horizontal directions are ambiguous for navigation of a vertical list.

On 2013-10-01 12:01, Lucas Sandery [three am design] wrote:

I meant LTR languages but I'm guessing that, if their is a RTL version of gitk, it needs fixing, too.

On 13-09-30 10:31 PM, Lucas Sandery [three am design] wrote:

I agree with you here (I like "older" and "newer" myself).

In theory gitk accepts the same arguments as "git rev-list", and in theory you should be able to use things like --reverse to get the commits in a different order.

However, in practice I don't think anyone futzes with the ordering much with gitk. gitk even ignores the --reverse and --timestamp options, and I've had a hard time getting gitk to display commits in an order where "older" and "newer" would not make sense.

Here I don't agree. These arrows are purely about history navigation. They don't have anything to do with "up" or "down" in the list. In that sense they're more like the arrows in your web browser.

		M.

Hi,

Marc Branchaud wrote:

In a branchy history, it is possible for the next matching commit to actually be newer. I think the intent of the buttons is "find the next result, looking down or up in the list of commits in the upper pane". Is there some other wording that would convey this better?

True. It might make sense to make the analogy to a web browser clearer by using thicker arrows or triangles --- care to mock up icons to replace the current ones?

The icons are in the gitk source file (search for "bm_left_data") in xpm format.

Hope that helps, Jonathan

On 13-10-08 03:36 PM, Jonathan Nieder wrote:

Chronologically, yes.

Gitk will often display a history like this (here the numbers represent commit dates, so 1 is the oldest commit, and I've rotated this 90 degrees clockwise from how gitk would display it):

--3--4-------5---
            /
--------1--2

If commits 2 and 4 match, and the user is looking at commit 2, then the "next" matching commit from 2 is 4, which is chronologically newer.

However, I still find it more intuitive to think of commit 4 as "older" than commit 2, at least when using gitk. This is because in gitk the commits are generally older as you go down the list. (When it comes to branches, chronology hardly matters anyway. In fact, gitk could ensure that all commits are displayed in strictly chronological order regardless of branches, and such a display would be just as correct as what it currently shows although it'd be less compact.)

A gitk user comes to expect older commits to be lower down in the display. It's certainly not a hard-and-fast rule, but it's a general paradigm that works.

The problem is, at least for me, that when I'm using gitk to browse the history of changes to a file, I'll often want to see things that happened before or after a certain point. Once I start thinking like that, gitk's concepts of "next" and "prev" mix me up, because I want to see the next thing that happened to the file but the "next" button doesn't take me there. The chronological (dis)ordering that branches introduce doesn't trip me up as much as the "next" and "prev" buttons.

		M.

Users often find that "next" and "prev" do the opposite of what they expect. For example, "next" moves to the next match down the list, but that is almost always backwards in time. Replacing the text with arrows makes it clear where the buttons will take the user.

Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
---

Finally got around to drawing some up and down arrows.

		M.

 gitk | 30 ++++++++++++++++++++++++++++--
 1 file changed, 28 insertions(+), 2 deletions(-)

On 13-12-18 11:04 AM, Marc Branchaud wrote:

Any opinions on this, either way?

I've grown fond of the down/up arrows. I find them much clearer than the current next/prev buttons.

My only niggle about this patch is that the buttons are much smaller, requiring a bit more precision clicking. But the smaller buttons allow more room for other widgets.

		M.

On Tue, Jan 21, 2014 at 10:33:02AM -0500, Marc Branchaud wrote:

I showed it to a few colleagues who use gitk a lot. One was indifferent, the others liked it, so I have applied it.

Thanks, Paul.

Paul Mackerras <paulus@samba.org> writes:

Is this a good time for me to pull from you? I see these on your 'master' branch.

    8f86339 gitk: Comply with XDG base directory specification
    786f15c gitk: Replace "next" and "prev" buttons with down and up arrows
    c61f3a9 gitk: chmod +x po2msg.sh
    6c626a0 gitk: Update copyright dates
    45f884c gitk: Add Bulgarian translation (304t)
    1f3c872 gitk: Fix mistype

Thanks.

On Wed, Jan 22, 2014 at 12:18:27PM -0800, Junio C Hamano wrote:

Yes, please pull.  I have just pushed one more:

	76d64ca gitk: Indent word-wrapped lines in commit display header

Thanks, Paul.

Paul Mackerras <paulus@samba.org> writes:

Thanks.

Users often find that "next" and "prev" do the opposite of what they expect. For example, "next" moves to the next match down the list, but that is almost always backwards in time. Renaming "next" to "older" and "prev" to "newer" makes it clear where the buttons will take the user. ---

(Apologies to Lucas and Paul -- my previous patch email didn't include the git list.)

 gitk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)