gitk next/prev buttons

gitk next/prev buttons

[Lucas Sandery [three am design]]

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.

Re: gitk next/prev buttons

[Lucas Sandery]

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

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

Re: gitk next/prev buttons

[Marc Branchaud]

On 13-09-30 10:31 PM, Lucas Sandery [three am design] wrote:
> 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.

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.

> 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.

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.

Re: gitk next/prev buttons

[Jonathan Nieder]

Hi,

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

>> The "next" and "prev" buttons are lacking consistency and logic. For LTR
>> 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.
>
> 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.

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?

>> 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.
>
> 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.

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

Re: gitk next/prev buttons

[Marc Branchaud]

On 13-10-08 03:36 PM, Jonathan Nieder wrote:
> 
> In a branchy history, it is possible for the next matching commit to
> actually be newer.

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.

> 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?

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.

[PATCH] gitk: Rename "next" and "prev" buttons to "older" and "newer".

[Marc Branchaud]

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(-)

diff --git a/gitk b/gitk
index 5cd00d8..e610010 100755
--- a/gitk
+++ b/gitk
@@ -2244,8 +2244,8 @@ proc makewindow {} {
 
     # build up the bottom bar of upper window
     ${NS}::label .tf.lbar.flabel -text "[mc "Find"] "
-    ${NS}::button .tf.lbar.fnext -text [mc "next"] -command {dofind 1 1}
-    ${NS}::button .tf.lbar.fprev -text [mc "prev"] -command {dofind -1 1}
+    ${NS}::button .tf.lbar.fnext -text [mc "older"] -command {dofind 1 1}
+    ${NS}::button .tf.lbar.fprev -text [mc "newer"] -command {dofind -1 1}
     ${NS}::label .tf.lbar.flab2 -text " [mc "commit"] "
     pack .tf.lbar.flabel .tf.lbar.fnext .tf.lbar.fprev .tf.lbar.flab2 \
 	-side left -fill y
-- 
1.8.4.dirty

[PATCHv2] gitk: Replace "next" and "prev" buttons with down and up arrows.

[Marc Branchaud]

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(-)

diff --git a/gitk b/gitk
index 33c3a6c..abd2ef3 100755
--- a/gitk
+++ b/gitk
@@ -2263,9 +2263,35 @@ proc makewindow {} {
 
     # build up the bottom bar of upper window
     ${NS}::label .tf.lbar.flabel -text "[mc "Find"] "
-    ${NS}::button .tf.lbar.fnext -text [mc "next"] -command {dofind 1 1}
-    ${NS}::button .tf.lbar.fprev -text [mc "prev"] -command {dofind -1 1}
+
+    set bm_down_data {
+	#define down_width 16
+	#define down_height 16
+	static unsigned char down_bits[] = {
+	0x80, 0x01, 0x80, 0x01, 0x80, 0x01, 0x80, 0x01,
+	0x80, 0x01, 0x80, 0x01, 0x80, 0x01, 0x80, 0x01,
+	0x87, 0xe1, 0x8e, 0x71, 0x9c, 0x39, 0xb8, 0x1d,
+	0xf0, 0x0f, 0xe0, 0x07, 0xc0, 0x03, 0x80, 0x01};
+    }
+    image create bitmap bm-down -data $bm_down_data -foreground $uifgcolor
+    ${NS}::button .tf.lbar.fnext -width 26 -command {dofind 1 1}
+    .tf.lbar.fnext configure -image bm-down
+
+    set bm_up_data {
+	#define up_width 16
+	#define up_height 16
+	static unsigned char up_bits[] = {
+	0x80, 0x01, 0xc0, 0x03, 0xe0, 0x07, 0xf0, 0x0f,
+	0xb8, 0x1d, 0x9c, 0x39, 0x8e, 0x71, 0x87, 0xe1,
+	0x80, 0x01, 0x80, 0x01, 0x80, 0x01, 0x80, 0x01,
+	0x80, 0x01, 0x80, 0x01, 0x80, 0x01, 0x80, 0x01};
+    }
+    image create bitmap bm-up -data $bm_up_data -foreground $uifgcolor
+    ${NS}::button .tf.lbar.fprev -width 26 -command {dofind -1 1}
+    .tf.lbar.fprev configure -image bm-up
+
     ${NS}::label .tf.lbar.flab2 -text " [mc "commit"] "
+
     pack .tf.lbar.flabel .tf.lbar.fnext .tf.lbar.fprev .tf.lbar.flab2 \
 	-side left -fill y
     set gdttype [mc "containing:"]
-- 
1.8.5.2.2.g49768e2

Re: [PATCHv2] gitk: Replace "next" and "prev" buttons with down and up arrows.

[Marc Branchaud]

On 13-12-18 11:04 AM, Marc Branchaud wrote:
> 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.

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.


> 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(-)
> 
> diff --git a/gitk b/gitk
> index 33c3a6c..abd2ef3 100755
> --- a/gitk
> +++ b/gitk
> @@ -2263,9 +2263,35 @@ proc makewindow {} {
>  
>      # build up the bottom bar of upper window
>      ${NS}::label .tf.lbar.flabel -text "[mc "Find"] "
> -    ${NS}::button .tf.lbar.fnext -text [mc "next"] -command {dofind 1 1}
> -    ${NS}::button .tf.lbar.fprev -text [mc "prev"] -command {dofind -1 1}
> +
> +    set bm_down_data {
> +	#define down_width 16
> +	#define down_height 16
> +	static unsigned char down_bits[] = {
> +	0x80, 0x01, 0x80, 0x01, 0x80, 0x01, 0x80, 0x01,
> +	0x80, 0x01, 0x80, 0x01, 0x80, 0x01, 0x80, 0x01,
> +	0x87, 0xe1, 0x8e, 0x71, 0x9c, 0x39, 0xb8, 0x1d,
> +	0xf0, 0x0f, 0xe0, 0x07, 0xc0, 0x03, 0x80, 0x01};
> +    }
> +    image create bitmap bm-down -data $bm_down_data -foreground $uifgcolor
> +    ${NS}::button .tf.lbar.fnext -width 26 -command {dofind 1 1}
> +    .tf.lbar.fnext configure -image bm-down
> +
> +    set bm_up_data {
> +	#define up_width 16
> +	#define up_height 16
> +	static unsigned char up_bits[] = {
> +	0x80, 0x01, 0xc0, 0x03, 0xe0, 0x07, 0xf0, 0x0f,
> +	0xb8, 0x1d, 0x9c, 0x39, 0x8e, 0x71, 0x87, 0xe1,
> +	0x80, 0x01, 0x80, 0x01, 0x80, 0x01, 0x80, 0x01,
> +	0x80, 0x01, 0x80, 0x01, 0x80, 0x01, 0x80, 0x01};
> +    }
> +    image create bitmap bm-up -data $bm_up_data -foreground $uifgcolor
> +    ${NS}::button .tf.lbar.fprev -width 26 -command {dofind -1 1}
> +    .tf.lbar.fprev configure -image bm-up
> +
>      ${NS}::label .tf.lbar.flab2 -text " [mc "commit"] "
> +
>      pack .tf.lbar.flabel .tf.lbar.fnext .tf.lbar.fprev .tf.lbar.flab2 \
>  	-side left -fill y
>      set gdttype [mc "containing:"]
> 

Re: [PATCHv2] gitk: Replace "next" and "prev" buttons with down and up arrows.

[Paul Mackerras]

On Tue, Jan 21, 2014 at 10:33:02AM -0500, Marc Branchaud wrote:
> On 13-12-18 11:04 AM, Marc Branchaud wrote:
> > 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.
> 
> 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.

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.

Re: [PATCHv2] gitk: Replace "next" and "prev" buttons with down and up arrows.

[Junio C Hamano]

Paul Mackerras <paulus@samba.org> writes:

> On Tue, Jan 21, 2014 at 10:33:02AM -0500, Marc Branchaud wrote:
>> On 13-12-18 11:04 AM, Marc Branchaud wrote:
>> > 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.
>> 
>> 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.
>
> 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.

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.

Re: [PATCHv2] gitk: Replace "next" and "prev" buttons with down and up arrows.

[Paul Mackerras]

On Wed, Jan 22, 2014 at 12:18:27PM -0800, Junio C Hamano wrote:
> 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.

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

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

Thanks,
Paul.

Re: [PATCHv2] gitk: Replace "next" and "prev" buttons with down and up arrows.

[Junio C Hamano]

Paul Mackerras <paulus@samba.org> writes:

> Yes, please pull.  I have just pushed one more:
>
> 	76d64ca gitk: Indent word-wrapped lines in commit display header

Thanks.