* [PATCH 00/13] gitk: tweak rendering of remote-tracking references
@ 2016-12-19 16:44 Michael Haggerty
2016-12-19 16:45 ` [PATCH 01/13] gitk: when processing tag labels, don't use `marks` as scratch space Michael Haggerty
` (15 more replies)
0 siblings, 16 replies; 24+ messages in thread
From: Michael Haggerty @ 2016-12-19 16:44 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Michael Haggerty
This patch series changes a bunch of details about how remote-tracking
references are rendered in the commit list of gitk:
* Omit the "remote/" prefix on normal remote-tracking references. They
are already distinguished via their two-tone rendering and (usually)
longer names, and this change saves a lot of visual clutter and
horizontal space.
* Render remote-tracking references that have more than the usual
three slashes like
origin/foo/bar
^^^^^^^
rather than
origin/foo/bar (formerly remotes/origin/foo/bar)
^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^
, where the indicated part is the prefix that is rendered in a
different color. Usually, such a reference represents a remote
branch that contains a slash in its name, so the new split more
accurately portrays the separation between remote name and remote
branch name.
* Introduce a separate constant to specify the background color used
for the branch name part of remote-tracking references, to allow it
to differ from the color used for local branches (which by default
is bright green).
* Change the default background colors for remote-tracking branches to
light brown and brown (formerly they were pale orange and bright
green).
I understand that the colors of pixels on computer screens is an even
more emotional topic that that of bikesheds, so I implemented the last
change as a separate commit, the last one in the series. Feel free to
drop it if you don't want the default color change.
Along the way, I did a bunch of refactoring in the area to make these
changes easier, and introduced a constant for the background color of
"other" references so that it can also be adjusted by users.
(Unfortunately, these colors can only be adjusted by editing the
configuration file. Someday it would be nice to allow them to be
configured via the preferences dialog.)
It's been a while since I've written any Tcl code, so I apologize in
advance for any howlers :-)
This branch applies against the `master` branch in
git://ozlabs.org/~paulus/gitk.
Michael
Michael Haggerty (13):
gitk: when processing tag labels, don't use `marks` as scratch space
gitk: keep track of tag types in a separate `types` array
gitk: use a type "tags" to indicate abbreviated tags
gitk: use a type "mainhead" to indicate the main HEAD branch
gitk: fill in `wvals` as the tags are first processed
gitk: simplify regexp
gitk: extract a method `remotereftext`
gitk: only change the color of the "remote" part of remote refs
gitk: shorten labels displayed for modern remote-tracking refs
gitk: use type "remote" for remote-tracking references
gitk: introduce a constant otherrefbgcolor
gitk: add a configuration setting `remoterefbgcolor`
gitk: change the default colors for remote-tracking references
gitk | 114 ++++++++++++++++++++++++++++++++++++++++++++-----------------------
1 file changed, 76 insertions(+), 38 deletions(-)
--
2.9.3
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 01/13] gitk: when processing tag labels, don't use `marks` as scratch space
2016-12-19 16:44 [PATCH 00/13] gitk: tweak rendering of remote-tracking references Michael Haggerty
@ 2016-12-19 16:45 ` Michael Haggerty
2016-12-19 16:45 ` [PATCH 02/13] gitk: keep track of tag types in a separate `types` array Michael Haggerty
` (14 subsequent siblings)
15 siblings, 0 replies; 24+ messages in thread
From: Michael Haggerty @ 2016-12-19 16:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Michael Haggerty
Instead, just append to it as necessary.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
gitk | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/gitk b/gitk
index a14d7a1..296efb3 100755
--- a/gitk
+++ b/gitk
@@ -6570,18 +6570,20 @@ proc drawtags {id x xt y1} {
set extra [expr {$delta + $lthickness + $linespc}]
if {[info exists idtags($id)]} {
- set marks $idtags($id)
- set ntags [llength $marks]
+ set tags $idtags($id)
+ set ntags [llength $tags]
if {$ntags > $maxtags ||
- [totalwidth $marks mainfont $extra] > $maxwidth} {
+ [totalwidth $tags mainfont $extra] > $maxwidth} {
# show just a single "n tags..." tag
set singletag 1
if {$ntags == 1} {
- set marks [list "tag..."]
+ lappend marks "tag..."
} else {
- set marks [list [format "%d tags..." $ntags]]
+ lappend marks [format "%d tags..." $ntags]
+ set ntags 1
}
- set ntags 1
+ } else {
+ set marks [concat $marks $tags]
}
}
if {[info exists idheads($id)]} {
--
2.9.3
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH 02/13] gitk: keep track of tag types in a separate `types` array
2016-12-19 16:44 [PATCH 00/13] gitk: tweak rendering of remote-tracking references Michael Haggerty
2016-12-19 16:45 ` [PATCH 01/13] gitk: when processing tag labels, don't use `marks` as scratch space Michael Haggerty
@ 2016-12-19 16:45 ` Michael Haggerty
2016-12-19 16:45 ` [PATCH 03/13] gitk: use a type "tags" to indicate abbreviated tags Michael Haggerty
` (13 subsequent siblings)
15 siblings, 0 replies; 24+ messages in thread
From: Michael Haggerty @ 2016-12-19 16:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Michael Haggerty
The resulting code is easier to follow than the old counting-based code,
plus in a moment we will add some more specific types.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
gitk | 37 +++++++++++++++++++++----------------
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/gitk b/gitk
index 296efb3..7c830c3 100755
--- a/gitk
+++ b/gitk
@@ -6560,8 +6560,7 @@ proc drawtags {id x xt y1} {
global reflinecolor
set marks {}
- set ntags 0
- set nheads 0
+ set types {}
set singletag 0
set maxtags 3
set maxtagpct 25
@@ -6576,22 +6575,30 @@ proc drawtags {id x xt y1} {
[totalwidth $tags mainfont $extra] > $maxwidth} {
# show just a single "n tags..." tag
set singletag 1
+ lappend types tag
if {$ntags == 1} {
lappend marks "tag..."
} else {
lappend marks [format "%d tags..." $ntags]
- set ntags 1
}
} else {
- set marks [concat $marks $tags]
+ foreach tag $tags {
+ lappend types tag
+ lappend marks $tag
+ }
}
}
if {[info exists idheads($id)]} {
- set marks [concat $marks $idheads($id)]
- set nheads [llength $idheads($id)]
+ foreach head $idheads($id) {
+ lappend types head
+ lappend marks $head
+ }
}
if {[info exists idotherrefs($id)]} {
- set marks [concat $marks $idotherrefs($id)]
+ foreach other $idotherrefs($id) {
+ lappend types other
+ lappend marks $other
+ }
}
if {$marks eq {}} {
return $xt
@@ -6601,10 +6608,8 @@ proc drawtags {id x xt y1} {
set yb [expr {$yt + $linespc - 1}]
set xvals {}
set wvals {}
- set i -1
- foreach tag $marks {
- incr i
- if {$i >= $ntags && $i < $ntags + $nheads && $tag eq $mainhead} {
+ foreach tag $marks type $types {
+ if {$type eq "head" && $tag eq $mainhead} {
set wid [font measure mainfontbold $tag]
} else {
set wid [font measure mainfont $tag]
@@ -6616,12 +6621,12 @@ proc drawtags {id x xt y1} {
set t [$canv create line $x $y1 [lindex $xvals end] $y1 \
-width $lthickness -fill $reflinecolor -tags tag.$id]
$canv lower $t
- foreach tag $marks x $xvals wid $wvals {
+ foreach tag $marks type $types x $xvals wid $wvals {
set tag_quoted [string map {% %%} $tag]
set xl [expr {$x + $delta}]
set xr [expr {$x + $delta + $wid + $lthickness}]
set font mainfont
- if {[incr ntags -1] >= 0} {
+ if {$type eq "tag"} {
# draw a tag
set t [$canv create polygon $x [expr {$yt + $delta}] $xl $yt \
$xr $yt $xr $yb $xl $yb $x [expr {$yb - $delta}] \
@@ -6636,7 +6641,7 @@ proc drawtags {id x xt y1} {
set rowtextx([rowofcommit $id]) [expr {$xr + $linespc}]
} else {
# draw a head or other ref
- if {[incr nheads -1] >= 0} {
+ if {$type eq "head"} {
set col $headbgcolor
if {$tag eq $mainhead} {
set font mainfontbold
@@ -6658,9 +6663,9 @@ proc drawtags {id x xt y1} {
}
set t [$canv create text $xl $y1 -anchor w -text $tag -fill $headfgcolor \
-font $font -tags [list tag.$id text]]
- if {$ntags >= 0} {
+ if {$type eq "tag"} {
$canv bind $t <1> $tagclick
- } elseif {$nheads >= 0} {
+ } elseif {$type eq "head"} {
$canv bind $t $ctxbut [list headmenu %X %Y $id $tag_quoted]
}
}
--
2.9.3
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH 03/13] gitk: use a type "tags" to indicate abbreviated tags
2016-12-19 16:44 [PATCH 00/13] gitk: tweak rendering of remote-tracking references Michael Haggerty
2016-12-19 16:45 ` [PATCH 01/13] gitk: when processing tag labels, don't use `marks` as scratch space Michael Haggerty
2016-12-19 16:45 ` [PATCH 02/13] gitk: keep track of tag types in a separate `types` array Michael Haggerty
@ 2016-12-19 16:45 ` Michael Haggerty
2016-12-19 16:45 ` [PATCH 04/13] gitk: use a type "mainhead" to indicate the main HEAD branch Michael Haggerty
` (12 subsequent siblings)
15 siblings, 0 replies; 24+ messages in thread
From: Michael Haggerty @ 2016-12-19 16:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Michael Haggerty
This replaces the functionality of the old `singletag` variable.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
gitk | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/gitk b/gitk
index 7c830c3..502f0aa 100755
--- a/gitk
+++ b/gitk
@@ -6561,7 +6561,6 @@ proc drawtags {id x xt y1} {
set marks {}
set types {}
- set singletag 0
set maxtags 3
set maxtagpct 25
set maxwidth [expr {[graph_pane_width] * $maxtagpct / 100}]
@@ -6574,8 +6573,7 @@ proc drawtags {id x xt y1} {
if {$ntags > $maxtags ||
[totalwidth $tags mainfont $extra] > $maxwidth} {
# show just a single "n tags..." tag
- set singletag 1
- lappend types tag
+ lappend types tags
if {$ntags == 1} {
lappend marks "tag..."
} else {
@@ -6626,13 +6624,13 @@ proc drawtags {id x xt y1} {
set xl [expr {$x + $delta}]
set xr [expr {$x + $delta + $wid + $lthickness}]
set font mainfont
- if {$type eq "tag"} {
+ if {$type eq "tag" || $type eq "tags"} {
# draw a tag
set t [$canv create polygon $x [expr {$yt + $delta}] $xl $yt \
$xr $yt $xr $yb $xl $yb $x [expr {$yb - $delta}] \
-width 1 -outline $tagoutlinecolor -fill $tagbgcolor \
-tags tag.$id]
- if {$singletag} {
+ if {$type eq "tags"} {
set tagclick [list showtags $id 1]
} else {
set tagclick [list showtag $tag_quoted 1]
@@ -6663,7 +6661,7 @@ proc drawtags {id x xt y1} {
}
set t [$canv create text $xl $y1 -anchor w -text $tag -fill $headfgcolor \
-font $font -tags [list tag.$id text]]
- if {$type eq "tag"} {
+ if {$type eq "tag" || $type eq "tags"} {
$canv bind $t <1> $tagclick
} elseif {$type eq "head"} {
$canv bind $t $ctxbut [list headmenu %X %Y $id $tag_quoted]
--
2.9.3
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH 04/13] gitk: use a type "mainhead" to indicate the main HEAD branch
2016-12-19 16:44 [PATCH 00/13] gitk: tweak rendering of remote-tracking references Michael Haggerty
` (2 preceding siblings ...)
2016-12-19 16:45 ` [PATCH 03/13] gitk: use a type "tags" to indicate abbreviated tags Michael Haggerty
@ 2016-12-19 16:45 ` Michael Haggerty
2016-12-19 16:45 ` [PATCH 05/13] gitk: fill in `wvals` as the tags are first processed Michael Haggerty
` (11 subsequent siblings)
15 siblings, 0 replies; 24+ messages in thread
From: Michael Haggerty @ 2016-12-19 16:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Michael Haggerty
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
gitk | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/gitk b/gitk
index 502f0aa..d2e3803 100755
--- a/gitk
+++ b/gitk
@@ -6588,7 +6588,11 @@ proc drawtags {id x xt y1} {
}
if {[info exists idheads($id)]} {
foreach head $idheads($id) {
- lappend types head
+ if {$head eq $mainhead} {
+ lappend types mainhead
+ } else {
+ lappend types head
+ }
lappend marks $head
}
}
@@ -6607,7 +6611,7 @@ proc drawtags {id x xt y1} {
set xvals {}
set wvals {}
foreach tag $marks type $types {
- if {$type eq "head" && $tag eq $mainhead} {
+ if {$type eq "mainhead"} {
set wid [font measure mainfontbold $tag]
} else {
set wid [font measure mainfont $tag]
@@ -6639,11 +6643,11 @@ proc drawtags {id x xt y1} {
set rowtextx([rowofcommit $id]) [expr {$xr + $linespc}]
} else {
# draw a head or other ref
- if {$type eq "head"} {
+ if {$type eq "mainhead"} {
+ set col $headbgcolor
+ set font mainfontbold
+ } elseif {$type eq "head"} {
set col $headbgcolor
- if {$tag eq $mainhead} {
- set font mainfontbold
- }
} else {
set col "#ddddff"
}
@@ -6663,7 +6667,7 @@ proc drawtags {id x xt y1} {
-font $font -tags [list tag.$id text]]
if {$type eq "tag" || $type eq "tags"} {
$canv bind $t <1> $tagclick
- } elseif {$type eq "head"} {
+ } elseif {$type eq "head" || $type eq "mainhead"} {
$canv bind $t $ctxbut [list headmenu %X %Y $id $tag_quoted]
}
}
--
2.9.3
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH 05/13] gitk: fill in `wvals` as the tags are first processed
2016-12-19 16:44 [PATCH 00/13] gitk: tweak rendering of remote-tracking references Michael Haggerty
` (3 preceding siblings ...)
2016-12-19 16:45 ` [PATCH 04/13] gitk: use a type "mainhead" to indicate the main HEAD branch Michael Haggerty
@ 2016-12-19 16:45 ` Michael Haggerty
2016-12-19 16:45 ` [PATCH 06/13] gitk: simplify regexp Michael Haggerty
` (10 subsequent siblings)
15 siblings, 0 replies; 24+ messages in thread
From: Michael Haggerty @ 2016-12-19 16:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Michael Haggerty
It's no longer, and a little bit more direct, to fill in `wvals` at the
same time as we determine the tag's type.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
gitk | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/gitk b/gitk
index d2e3803..fb2f653 100755
--- a/gitk
+++ b/gitk
@@ -6561,6 +6561,7 @@ proc drawtags {id x xt y1} {
set marks {}
set types {}
+ set wvals {}
set maxtags 3
set maxtagpct 25
set maxwidth [expr {[graph_pane_width] * $maxtagpct / 100}]
@@ -6575,14 +6576,17 @@ proc drawtags {id x xt y1} {
# show just a single "n tags..." tag
lappend types tags
if {$ntags == 1} {
- lappend marks "tag..."
+ set text "tag..."
} else {
- lappend marks [format "%d tags..." $ntags]
+ set text [format "%d tags..." $ntags]
}
+ lappend marks $text
+ lappend wvals [font measure mainfont $text]
} else {
foreach tag $tags {
lappend types tag
lappend marks $tag
+ lappend wvals [font measure mainfont $tag]
}
}
}
@@ -6590,8 +6594,10 @@ proc drawtags {id x xt y1} {
foreach head $idheads($id) {
if {$head eq $mainhead} {
lappend types mainhead
+ lappend wvals [font measure mainfontbold $head]
} else {
lappend types head
+ lappend wvals [font measure mainfont $head]
}
lappend marks $head
}
@@ -6600,6 +6606,7 @@ proc drawtags {id x xt y1} {
foreach other $idotherrefs($id) {
lappend types other
lappend marks $other
+ lappend wvals [font measure mainfont $other]
}
}
if {$marks eq {}} {
@@ -6609,15 +6616,8 @@ proc drawtags {id x xt y1} {
set yt [expr {$y1 - 0.5 * $linespc}]
set yb [expr {$yt + $linespc - 1}]
set xvals {}
- set wvals {}
- foreach tag $marks type $types {
- if {$type eq "mainhead"} {
- set wid [font measure mainfontbold $tag]
- } else {
- set wid [font measure mainfont $tag]
- }
+ foreach wid $wvals {
lappend xvals $xt
- lappend wvals $wid
set xt [expr {$xt + $wid + $extra}]
}
set t [$canv create line $x $y1 [lindex $xvals end] $y1 \
--
2.9.3
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH 06/13] gitk: simplify regexp
2016-12-19 16:44 [PATCH 00/13] gitk: tweak rendering of remote-tracking references Michael Haggerty
` (4 preceding siblings ...)
2016-12-19 16:45 ` [PATCH 05/13] gitk: fill in `wvals` as the tags are first processed Michael Haggerty
@ 2016-12-19 16:45 ` Michael Haggerty
2016-12-19 16:45 ` [PATCH 07/13] gitk: extract a method `remotereftext` Michael Haggerty
` (9 subsequent siblings)
15 siblings, 0 replies; 24+ messages in thread
From: Michael Haggerty @ 2016-12-19 16:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Michael Haggerty
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
gitk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitk b/gitk
index fb2f653..84a5326 100755
--- a/gitk
+++ b/gitk
@@ -6654,7 +6654,7 @@ proc drawtags {id x xt y1} {
set xl [expr {$xl - $delta/2}]
$canv create polygon $x $yt $xr $yt $xr $yb $x $yb \
-width 1 -outline black -fill $col -tags tag.$id
- if {[regexp {^(remotes/.*/|remotes/)} $tag match remoteprefix]} {
+ if {[regexp {^(remotes/(.*/|))} $tag match remoteprefix]} {
set rwid [font measure mainfont $remoteprefix]
set xi [expr {$x + 1}]
set yti [expr {$yt + 1}]
--
2.9.3
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH 07/13] gitk: extract a method `remotereftext`
2016-12-19 16:44 [PATCH 00/13] gitk: tweak rendering of remote-tracking references Michael Haggerty
` (5 preceding siblings ...)
2016-12-19 16:45 ` [PATCH 06/13] gitk: simplify regexp Michael Haggerty
@ 2016-12-19 16:45 ` Michael Haggerty
2016-12-19 16:45 ` [PATCH 08/13] gitk: only change the color of the "remote" part of remote refs Michael Haggerty
` (8 subsequent siblings)
15 siblings, 0 replies; 24+ messages in thread
From: Michael Haggerty @ 2016-12-19 16:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Michael Haggerty
The text value that it also provides to its caller is not used yet, but
it will be soon.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
gitk | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/gitk b/gitk
index 84a5326..51ebaf5 100755
--- a/gitk
+++ b/gitk
@@ -6551,6 +6551,22 @@ proc totalwidth {l font extra} {
return $tot
}
+# Set textName to the text that should be shown in the label for the
+# specified head and prefixName to the prefix text that should be
+# highlighted in $remotebgcolor. Return 1 iff $head is a remote head.
+proc remotereftext {head textName prefixName} {
+ upvar $textName text
+ upvar $prefixName prefix
+
+ if {[regexp {^((remotes/(.*/|)).*)} $head match text prefix]} {
+ return 1
+ } else {
+ set text $head
+ set prefix ""
+ return 0
+ }
+}
+
proc drawtags {id x xt y1} {
global idtags idheads idotherrefs mainhead
global linespc lthickness
@@ -6654,7 +6670,7 @@ proc drawtags {id x xt y1} {
set xl [expr {$xl - $delta/2}]
$canv create polygon $x $yt $xr $yt $xr $yb $x $yb \
-width 1 -outline black -fill $col -tags tag.$id
- if {[regexp {^(remotes/(.*/|))} $tag match remoteprefix]} {
+ if {[remotereftext $tag text remoteprefix]} {
set rwid [font measure mainfont $remoteprefix]
set xi [expr {$x + 1}]
set yti [expr {$yt + 1}]
--
2.9.3
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH 08/13] gitk: only change the color of the "remote" part of remote refs
2016-12-19 16:44 [PATCH 00/13] gitk: tweak rendering of remote-tracking references Michael Haggerty
` (6 preceding siblings ...)
2016-12-19 16:45 ` [PATCH 07/13] gitk: extract a method `remotereftext` Michael Haggerty
@ 2016-12-19 16:45 ` Michael Haggerty
2016-12-19 16:45 ` [PATCH 09/13] gitk: shorten labels displayed for modern remote-tracking refs Michael Haggerty
` (7 subsequent siblings)
15 siblings, 0 replies; 24+ messages in thread
From: Michael Haggerty @ 2016-12-19 16:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Michael Haggerty
If a remote-tracking reference has the form
refs/remotes/origin/foo/bar
, then the part of the reference that tells which remote it comes from
is `refs/remotes/origin`. So display such a reference as
remotes/origin/foo/bar
^^^^^^^^^^^^^^^
, where the indicated part is displayed in `$remotebgcolor`. The old
code always split the reference name at its last slash, thus rendering
the above remote-tracking reference as
remotes/origin/foo/bar
^^^^^^^^^^^^^^^^^^^
, which makes no sense at all.
Note that this commit doesn't change the rendering of remote-tracking
references with only two slashes (e.g., `refs/remotes/foo`). Such
references were created by `git-svn` when using its old naming scheme.
They are still rendered like
remotes/foo
^^^^^^^^
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
gitk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitk b/gitk
index 51ebaf5..c146a15 100755
--- a/gitk
+++ b/gitk
@@ -6558,7 +6558,7 @@ proc remotereftext {head textName prefixName} {
upvar $textName text
upvar $prefixName prefix
- if {[regexp {^((remotes/(.*/|)).*)} $head match text prefix]} {
+ if {[regexp {^((remotes/([^/]+/|)).*)} $head match text prefix]} {
return 1
} else {
set text $head
--
2.9.3
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH 09/13] gitk: shorten labels displayed for modern remote-tracking refs
2016-12-19 16:44 [PATCH 00/13] gitk: tweak rendering of remote-tracking references Michael Haggerty
` (7 preceding siblings ...)
2016-12-19 16:45 ` [PATCH 08/13] gitk: only change the color of the "remote" part of remote refs Michael Haggerty
@ 2016-12-19 16:45 ` Michael Haggerty
2016-12-19 16:45 ` [PATCH 10/13] gitk: use type "remote" for remote-tracking references Michael Haggerty
` (6 subsequent siblings)
15 siblings, 0 replies; 24+ messages in thread
From: Michael Haggerty @ 2016-12-19 16:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Michael Haggerty
If a reference has the form
refs/remotes/origin/foo
, then use the label
origin/foo
^^^^^^^
, where the indicated part is displayed in `$remotebgcolor`. The old
code would have displayed such a reference as
remotes/origin/foo
^^^^^^^^^^^^^^^
, which wastes horizontal space displaying `remote/` for every remote
reference. However, if a remote-tracking reference has only two slashes,
like
refs/remotes/baz
, render the label the same as before, namely
remotes/baz
^^^^^^^^
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
gitk | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/gitk b/gitk
index c146a15..d22ce5f 100755
--- a/gitk
+++ b/gitk
@@ -6558,7 +6558,9 @@ proc remotereftext {head textName prefixName} {
upvar $textName text
upvar $prefixName prefix
- if {[regexp {^((remotes/([^/]+/|)).*)} $head match text prefix]} {
+ if {[regexp {^remotes/(([^/]+/).*)} $head match text prefix]} {
+ return 1
+ } elseif {[regexp {^((remotes/).*)} $head match text prefix]} {
return 1
} else {
set text $head
@@ -6613,7 +6615,8 @@ proc drawtags {id x xt y1} {
lappend wvals [font measure mainfontbold $head]
} else {
lappend types head
- lappend wvals [font measure mainfont $head]
+ remotereftext $head text remoteprefix
+ lappend wvals [font measure mainfont $text]
}
lappend marks $head
}
@@ -6644,6 +6647,7 @@ proc drawtags {id x xt y1} {
set xl [expr {$x + $delta}]
set xr [expr {$x + $delta + $wid + $lthickness}]
set font mainfont
+ set text $tag
if {$type eq "tag" || $type eq "tags"} {
# draw a tag
set t [$canv create polygon $x [expr {$yt + $delta}] $xl $yt \
@@ -6679,7 +6683,7 @@ proc drawtags {id x xt y1} {
-width 0 -fill $remotebgcolor -tags tag.$id
}
}
- set t [$canv create text $xl $y1 -anchor w -text $tag -fill $headfgcolor \
+ set t [$canv create text $xl $y1 -anchor w -text $text -fill $headfgcolor \
-font $font -tags [list tag.$id text]]
if {$type eq "tag" || $type eq "tags"} {
$canv bind $t <1> $tagclick
--
2.9.3
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH 10/13] gitk: use type "remote" for remote-tracking references
2016-12-19 16:44 [PATCH 00/13] gitk: tweak rendering of remote-tracking references Michael Haggerty
` (8 preceding siblings ...)
2016-12-19 16:45 ` [PATCH 09/13] gitk: shorten labels displayed for modern remote-tracking refs Michael Haggerty
@ 2016-12-19 16:45 ` Michael Haggerty
2016-12-19 16:45 ` [PATCH 11/13] gitk: introduce a constant otherrefbgcolor Michael Haggerty
` (5 subsequent siblings)
15 siblings, 0 replies; 24+ messages in thread
From: Michael Haggerty @ 2016-12-19 16:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Michael Haggerty
This is clearer, and also lets us avoid calling `remotereftext` a second
time for normal branches.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
gitk | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/gitk b/gitk
index d22ce5f..44f4d70 100755
--- a/gitk
+++ b/gitk
@@ -6613,9 +6613,11 @@ proc drawtags {id x xt y1} {
if {$head eq $mainhead} {
lappend types mainhead
lappend wvals [font measure mainfontbold $head]
+ } elseif {[remotereftext $head text remoteprefix]} {
+ lappend types remote
+ lappend wvals [font measure mainfont $text]
} else {
lappend types head
- remotereftext $head text remoteprefix
lappend wvals [font measure mainfont $text]
}
lappend marks $head
@@ -6666,7 +6668,7 @@ proc drawtags {id x xt y1} {
if {$type eq "mainhead"} {
set col $headbgcolor
set font mainfontbold
- } elseif {$type eq "head"} {
+ } elseif {$type eq "head" || $type eq "remote"} {
set col $headbgcolor
} else {
set col "#ddddff"
@@ -6674,7 +6676,8 @@ proc drawtags {id x xt y1} {
set xl [expr {$xl - $delta/2}]
$canv create polygon $x $yt $xr $yt $xr $yb $x $yb \
-width 1 -outline black -fill $col -tags tag.$id
- if {[remotereftext $tag text remoteprefix]} {
+ if {$type eq "remote"} {
+ remotereftext $tag text remoteprefix
set rwid [font measure mainfont $remoteprefix]
set xi [expr {$x + 1}]
set yti [expr {$yt + 1}]
--
2.9.3
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH 11/13] gitk: introduce a constant otherrefbgcolor
2016-12-19 16:44 [PATCH 00/13] gitk: tweak rendering of remote-tracking references Michael Haggerty
` (9 preceding siblings ...)
2016-12-19 16:45 ` [PATCH 10/13] gitk: use type "remote" for remote-tracking references Michael Haggerty
@ 2016-12-19 16:45 ` Michael Haggerty
2016-12-19 16:45 ` [PATCH 12/13] gitk: add a configuration setting `remoterefbgcolor` Michael Haggerty
` (4 subsequent siblings)
15 siblings, 0 replies; 24+ messages in thread
From: Michael Haggerty @ 2016-12-19 16:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Michael Haggerty
This is the value used for references other than tags, heads, and
remote-tracking references (e.g., `refs/stash`).
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
gitk | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/gitk b/gitk
index 44f4d70..0bd4aa5 100755
--- a/gitk
+++ b/gitk
@@ -6573,7 +6573,8 @@ proc drawtags {id x xt y1} {
global idtags idheads idotherrefs mainhead
global linespc lthickness
global canv rowtextx curview fgcolor bgcolor ctxbut
- global headbgcolor headfgcolor headoutlinecolor remotebgcolor
+ global headbgcolor headfgcolor headoutlinecolor
+ global remotebgcolor otherrefbgcolor
global tagbgcolor tagfgcolor tagoutlinecolor
global reflinecolor
@@ -6671,7 +6672,7 @@ proc drawtags {id x xt y1} {
} elseif {$type eq "head" || $type eq "remote"} {
set col $headbgcolor
} else {
- set col "#ddddff"
+ set col $otherrefbgcolor
}
set xl [expr {$xl - $delta/2}]
$canv create polygon $x $yt $xr $yt $xr $yb $x $yb \
@@ -12361,6 +12362,7 @@ set headbgcolor "#00ff00"
set headfgcolor black
set headoutlinecolor black
set remotebgcolor #ffddaa
+set otherrefbgcolor #ddddff
set tagbgcolor yellow
set tagfgcolor black
set tagoutlinecolor black
@@ -12418,7 +12420,8 @@ set config_variables {
bgcolor fgcolor uifgcolor uifgdisabledcolor colors diffcolors mergecolors
markbgcolor diffcontext selectbgcolor foundbgcolor currentsearchhitbgcolor
extdifftool perfile_attrs headbgcolor headfgcolor headoutlinecolor
- remotebgcolor tagbgcolor tagfgcolor tagoutlinecolor reflinecolor
+ remotebgcolor otherrefbgcolor
+ tagbgcolor tagfgcolor tagoutlinecolor reflinecolor
filesepbgcolor filesepfgcolor linehoverbgcolor linehoverfgcolor
linehoveroutlinecolor mainheadcirclecolor workingfilescirclecolor
indexcirclecolor circlecolors linkfgcolor circleoutlinecolor
--
2.9.3
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH 12/13] gitk: add a configuration setting `remoterefbgcolor`
2016-12-19 16:44 [PATCH 00/13] gitk: tweak rendering of remote-tracking references Michael Haggerty
` (10 preceding siblings ...)
2016-12-19 16:45 ` [PATCH 11/13] gitk: introduce a constant otherrefbgcolor Michael Haggerty
@ 2016-12-19 16:45 ` Michael Haggerty
2016-12-19 16:45 ` [PATCH 13/13] gitk: change the default colors for remote-tracking references Michael Haggerty
` (3 subsequent siblings)
15 siblings, 0 replies; 24+ messages in thread
From: Michael Haggerty @ 2016-12-19 16:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Michael Haggerty
Remote-tracking references are very different than local branches, so it
would be nice to make it possible to distinguish then visually. So allow
the remote reference background color to be configured separately from
the branch reference background color by introducing a new constant,
`remoterefbgcolor`. For the moment, leave it set to the old default
`headbgcolor`.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
gitk | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/gitk b/gitk
index 0bd4aa5..cb5c715 100755
--- a/gitk
+++ b/gitk
@@ -6574,7 +6574,7 @@ proc drawtags {id x xt y1} {
global linespc lthickness
global canv rowtextx curview fgcolor bgcolor ctxbut
global headbgcolor headfgcolor headoutlinecolor
- global remotebgcolor otherrefbgcolor
+ global remotebgcolor remoterefbgcolor otherrefbgcolor
global tagbgcolor tagfgcolor tagoutlinecolor
global reflinecolor
@@ -6669,8 +6669,10 @@ proc drawtags {id x xt y1} {
if {$type eq "mainhead"} {
set col $headbgcolor
set font mainfontbold
- } elseif {$type eq "head" || $type eq "remote"} {
+ } elseif {$type eq "head"} {
set col $headbgcolor
+ } elseif {$type eq "remote"} {
+ set col $remoterefbgcolor
} else {
set col $otherrefbgcolor
}
@@ -12362,6 +12364,7 @@ set headbgcolor "#00ff00"
set headfgcolor black
set headoutlinecolor black
set remotebgcolor #ffddaa
+set remoterefbgcolor #00ff00
set otherrefbgcolor #ddddff
set tagbgcolor yellow
set tagfgcolor black
@@ -12420,7 +12423,7 @@ set config_variables {
bgcolor fgcolor uifgcolor uifgdisabledcolor colors diffcolors mergecolors
markbgcolor diffcontext selectbgcolor foundbgcolor currentsearchhitbgcolor
extdifftool perfile_attrs headbgcolor headfgcolor headoutlinecolor
- remotebgcolor otherrefbgcolor
+ remotebgcolor remoterefbgcolor otherrefbgcolor
tagbgcolor tagfgcolor tagoutlinecolor reflinecolor
filesepbgcolor filesepfgcolor linehoverbgcolor linehoverfgcolor
linehoveroutlinecolor mainheadcirclecolor workingfilescirclecolor
--
2.9.3
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH 13/13] gitk: change the default colors for remote-tracking references
2016-12-19 16:44 [PATCH 00/13] gitk: tweak rendering of remote-tracking references Michael Haggerty
` (11 preceding siblings ...)
2016-12-19 16:45 ` [PATCH 12/13] gitk: add a configuration setting `remoterefbgcolor` Michael Haggerty
@ 2016-12-19 16:45 ` Michael Haggerty
2016-12-19 22:53 ` [PATCH 00/13] gitk: tweak rendering of " Philip Oakley
` (2 subsequent siblings)
15 siblings, 0 replies; 24+ messages in thread
From: Michael Haggerty @ 2016-12-19 16:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Michael Haggerty
Instead of coloring the reference name part of remote-tracking
references the same bright green as used for local branches, change it
to a subtler brown. Change the remote name color to go better with the
brown.
I chose these colors because
* Remote-tracking references are less important than local branches, so
it is appropriate that their coloring be subtler.
* Brown isn't used elsewhere.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
gitk | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitk b/gitk
index cb5c715..be97640 100755
--- a/gitk
+++ b/gitk
@@ -12363,8 +12363,8 @@ set markbgcolor "#e0e0ff"
set headbgcolor "#00ff00"
set headfgcolor black
set headoutlinecolor black
-set remotebgcolor #ffddaa
-set remoterefbgcolor #00ff00
+set remotebgcolor #d9d4b2
+set remoterefbgcolor #c1a677
set otherrefbgcolor #ddddff
set tagbgcolor yellow
set tagfgcolor black
--
2.9.3
^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references
2016-12-19 16:44 [PATCH 00/13] gitk: tweak rendering of remote-tracking references Michael Haggerty
` (12 preceding siblings ...)
2016-12-19 16:45 ` [PATCH 13/13] gitk: change the default colors for remote-tracking references Michael Haggerty
@ 2016-12-19 22:53 ` Philip Oakley
2016-12-20 8:03 ` Michael Haggerty
2016-12-20 15:01 ` Marc Branchaud
2017-02-06 17:13 ` Marc Branchaud
15 siblings, 1 reply; 24+ messages in thread
From: Philip Oakley @ 2016-12-19 22:53 UTC (permalink / raw)
To: Michael Haggerty, Paul Mackerras; +Cc: Git List, Michael Haggerty
From: "Michael Haggerty" <mhagger@alum.mit.edu>
> This patch series changes a bunch of details about how remote-tracking
> references are rendered in the commit list of gitk:
>
[...]
> * Introduce a separate constant to specify the background color used
> for the branch name part of remote-tracking references, to allow it
> to differ from the color used for local branches (which by default
> is bright green).
>
> * Change the default background colors for remote-tracking branches to
> light brown and brown (formerly they were pale orange and bright
> green).
>
> I understand that the colors of pixels on computer screens is an even
> more emotional topic that that of bikesheds, so I implemented the last
> change as a separate commit, the last one in the series. Feel free to
> drop it if you don't want the default color change.
>
Just to say that there was an issue with the bright green (lime) a while
back when 'green' changed its colour.
dscho reported in
(https://github.com/git-for-windows/git/issues/300#issuecomment-133702654
26 Aug 2015)
"[T]his is a change in Tk 8.6 described here (http://wiki.tcl.tk/1424): From
Tcl/Tk 8.6 on, Tk uses Web colours instead of X11 ones, where they
conflict."
In particular the old bright green version of 'green' became a darker green,
with the old colour becoming named lime.
For me, I needed to change my colour scheme (to a lime) as I could not read
the refs against the darker colour.
Anyway, that's the background as I know it.
--
Philip
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references
2016-12-19 22:53 ` [PATCH 00/13] gitk: tweak rendering of " Philip Oakley
@ 2016-12-20 8:03 ` Michael Haggerty
0 siblings, 0 replies; 24+ messages in thread
From: Michael Haggerty @ 2016-12-20 8:03 UTC (permalink / raw)
To: Philip Oakley, Paul Mackerras; +Cc: Git List
On 12/19/2016 11:53 PM, Philip Oakley wrote:
> From: "Michael Haggerty" <mhagger@alum.mit.edu>
>> This patch series changes a bunch of details about how remote-tracking
>> references are rendered in the commit list of gitk:
>>
> [...]
>> * Introduce a separate constant to specify the background color used
>> for the branch name part of remote-tracking references, to allow it
>> to differ from the color used for local branches (which by default
>> is bright green).
>>
>> * Change the default background colors for remote-tracking branches to
>> light brown and brown (formerly they were pale orange and bright
>> green).
>>
>> I understand that the colors of pixels on computer screens is an even
>> more emotional topic that that of bikesheds, so I implemented the last
>> change as a separate commit, the last one in the series. Feel free to
>> drop it if you don't want the default color change.
>
> Just to say that there was an issue with the bright green (lime) a while
> back when 'green' changed its colour.
>
> dscho reported in
> (https://github.com/git-for-windows/git/issues/300#issuecomment-133702654
> 26 Aug 2015)
>
> "[T]his is a change in Tk 8.6 described here (http://wiki.tcl.tk/1424):
> From
> Tcl/Tk 8.6 on, Tk uses Web colours instead of X11 ones, where they
> conflict."
>
> In particular the old bright green version of 'green' became a darker
> green,
> with the old colour becoming named lime.
>
> For me, I needed to change my colour scheme (to a lime) as I could not read
> the refs against the darker colour.
>
> Anyway, that's the background as I know it.
Thanks for the context. In fact, it was this color change that got me
looking at this code in the first place.
For anyone still suffering from the "green background of branch labels
in gitk got too dark" problem:
The default color in gitk was made lighter again in
66db14c "gitk: Color name update", 2015-10-25
But your own configuration might still have "green" written in it, from
the days when "green" was still bright. If so, change the value for
`headbgcolor` to `lime` in `~/.config/git/gitk`.
It would be nice if these colors were adjustable via the "Preferences ->
Colors" dialog.
Michael
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references
2016-12-19 16:44 [PATCH 00/13] gitk: tweak rendering of remote-tracking references Michael Haggerty
` (13 preceding siblings ...)
2016-12-19 22:53 ` [PATCH 00/13] gitk: tweak rendering of " Philip Oakley
@ 2016-12-20 15:01 ` Marc Branchaud
2016-12-20 22:17 ` Paul Mackerras
2016-12-21 0:05 ` Michael Haggerty
2017-02-06 17:13 ` Marc Branchaud
15 siblings, 2 replies; 24+ messages in thread
From: Marc Branchaud @ 2016-12-20 15:01 UTC (permalink / raw)
To: Michael Haggerty, Paul Mackerras; +Cc: git
On 2016-12-19 11:44 AM, Michael Haggerty wrote:
> This patch series changes a bunch of details about how remote-tracking
> references are rendered in the commit list of gitk:
Thanks for this! I like the new, compact look very much!
That said, I remember when I was a new git user and I leaned heavily on
gitk to understand how references worked. It was particularly
illuminating to see the remote references distinctly labeled, and the
fact that they were "remotes/origin/foo" gave me an Aha! moment where I
came to understand that the refs hierarchy is more flexible than just
the conventions coded into git itself. I eventually felt free to create
my own, private ref hierarchies.
I am in no way opposed to this series. I just wanted to point out that
there was some utility in those labels. It makes me think that it might
be worthwhile for gitk to have a "raw-refs" mode, that shows the full
"refs/foo/bar/baz" paths of all the heads, tags, and whatever else. It
could be a useful teaching tool for git.
> * Omit the "remote/" prefix on normal remote-tracking references. They
If you re-roll, s:remote/:remotes/:.
> are already distinguished via their two-tone rendering and (usually)
> longer names, and this change saves a lot of visual clutter and
> horizontal space.
>
> * Render remote-tracking references that have more than the usual
> three slashes like
>
> origin/foo/bar
> ^^^^^^^
>
> rather than
>
> origin/foo/bar (formerly remotes/origin/foo/bar)
> ^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^
>
> , where the indicated part is the prefix that is rendered in a
> different color. Usually, such a reference represents a remote
> branch that contains a slash in its name, so the new split more
> accurately portrays the separation between remote name and remote
> branch name.
*Love* this change! :)
> * Introduce a separate constant to specify the background color used
> for the branch name part of remote-tracking references, to allow it
> to differ from the color used for local branches (which by default
> is bright green).
>
> * Change the default background colors for remote-tracking branches to
> light brown and brown (formerly they were pale orange and bright
> green).
Please don't change the remotebgcolor default.
Also, perhaps the default remoterefbgcolor should be
set remoterefbgcolor $headbgcolor
?
I say this because when I applied the series, without the last patch, I
was miffed that the remote/ref colour had changed.
Plus I think there's utility in having local and remote branch names in
the same colour, again especially for new users. It helps emphasize
their similarities, and demystify some of git's internal magic.
M.
> I understand that the colors of pixels on computer screens is an even
> more emotional topic that that of bikesheds, so I implemented the last
> change as a separate commit, the last one in the series. Feel free to
> drop it if you don't want the default color change.
>
> Along the way, I did a bunch of refactoring in the area to make these
> changes easier, and introduced a constant for the background color of
> "other" references so that it can also be adjusted by users.
>
> (Unfortunately, these colors can only be adjusted by editing the
> configuration file. Someday it would be nice to allow them to be
> configured via the preferences dialog.)
>
> It's been a while since I've written any Tcl code, so I apologize in
> advance for any howlers :-)
>
> This branch applies against the `master` branch in
> git://ozlabs.org/~paulus/gitk.
>
> Michael
>
> Michael Haggerty (13):
> gitk: when processing tag labels, don't use `marks` as scratch space
> gitk: keep track of tag types in a separate `types` array
> gitk: use a type "tags" to indicate abbreviated tags
> gitk: use a type "mainhead" to indicate the main HEAD branch
> gitk: fill in `wvals` as the tags are first processed
> gitk: simplify regexp
> gitk: extract a method `remotereftext`
> gitk: only change the color of the "remote" part of remote refs
> gitk: shorten labels displayed for modern remote-tracking refs
> gitk: use type "remote" for remote-tracking references
> gitk: introduce a constant otherrefbgcolor
> gitk: add a configuration setting `remoterefbgcolor`
> gitk: change the default colors for remote-tracking references
>
> gitk | 114 ++++++++++++++++++++++++++++++++++++++++++++-----------------------
> 1 file changed, 76 insertions(+), 38 deletions(-)
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references
2016-12-20 15:01 ` Marc Branchaud
@ 2016-12-20 22:17 ` Paul Mackerras
2016-12-20 22:53 ` Marc Branchaud
2016-12-21 0:05 ` Michael Haggerty
1 sibling, 1 reply; 24+ messages in thread
From: Paul Mackerras @ 2016-12-20 22:17 UTC (permalink / raw)
To: Marc Branchaud; +Cc: Michael Haggerty, git
On Tue, Dec 20, 2016 at 10:01:15AM -0500, Marc Branchaud wrote:
> On 2016-12-19 11:44 AM, Michael Haggerty wrote:
> >This patch series changes a bunch of details about how remote-tracking
> >references are rendered in the commit list of gitk:
>
> Thanks for this! I like the new, compact look very much!
>
> That said, I remember when I was a new git user and I leaned heavily on gitk
> to understand how references worked. It was particularly illuminating to
> see the remote references distinctly labeled, and the fact that they were
> "remotes/origin/foo" gave me an Aha! moment where I came to understand that
> the refs hierarchy is more flexible than just the conventions coded into git
> itself. I eventually felt free to create my own, private ref hierarchies.
>
> I am in no way opposed to this series. I just wanted to point out that
> there was some utility in those labels. It makes me think that it might be
> worthwhile for gitk to have a "raw-refs" mode, that shows the full
> "refs/foo/bar/baz" paths of all the heads, tags, and whatever else. It
> could be a useful teaching tool for git.
Do you think we should have a checkbox in the preferences dialog to
select whether to display the long form or the short form?
Paul.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references
2016-12-20 22:17 ` Paul Mackerras
@ 2016-12-20 22:53 ` Marc Branchaud
0 siblings, 0 replies; 24+ messages in thread
From: Marc Branchaud @ 2016-12-20 22:53 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Michael Haggerty, git
On 2016-12-20 05:17 PM, Paul Mackerras wrote:
> On Tue, Dec 20, 2016 at 10:01:15AM -0500, Marc Branchaud wrote:
>> On 2016-12-19 11:44 AM, Michael Haggerty wrote:
>>> This patch series changes a bunch of details about how remote-tracking
>>> references are rendered in the commit list of gitk:
>>
>> Thanks for this! I like the new, compact look very much!
>>
>> That said, I remember when I was a new git user and I leaned heavily on gitk
>> to understand how references worked. It was particularly illuminating to
>> see the remote references distinctly labeled, and the fact that they were
>> "remotes/origin/foo" gave me an Aha! moment where I came to understand that
>> the refs hierarchy is more flexible than just the conventions coded into git
>> itself. I eventually felt free to create my own, private ref hierarchies.
>>
>> I am in no way opposed to this series. I just wanted to point out that
>> there was some utility in those labels. It makes me think that it might be
>> worthwhile for gitk to have a "raw-refs" mode, that shows the full
>> "refs/foo/bar/baz" paths of all the heads, tags, and whatever else. It
>> could be a useful teaching tool for git.
>
> Do you think we should have a checkbox in the preferences dialog to
> select whether to display the long form or the short form?
Mmmm, more knobs!
No, I don't think that's necessary. Such a setting would probably just
confuse people. Plus it's not something anyone is likely to want to
change anyway. Maybe if there were an "Advanced" tab in the settings
dialog, but even then it seems like overkill.
I suspect there are better ways to teach people about the refs hierarchy
than cluttering up gitk. These may even already exist -- I've been a
git user for 8 years now, so I'm sure my perspective of the learning
curve is skewed.
M.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references
2016-12-20 15:01 ` Marc Branchaud
2016-12-20 22:17 ` Paul Mackerras
@ 2016-12-21 0:05 ` Michael Haggerty
2016-12-21 19:07 ` Marc Branchaud
1 sibling, 1 reply; 24+ messages in thread
From: Michael Haggerty @ 2016-12-21 0:05 UTC (permalink / raw)
To: Marc Branchaud, Paul Mackerras; +Cc: git
On 12/20/2016 04:01 PM, Marc Branchaud wrote:
> On 2016-12-19 11:44 AM, Michael Haggerty wrote:
>> This patch series changes a bunch of details about how remote-tracking
>> references are rendered in the commit list of gitk:
>
> Thanks for this! I like the new, compact look very much!
>
> That said, I remember when I was a new git user and I leaned heavily on
> gitk to understand how references worked. It was particularly
> illuminating to see the remote references distinctly labeled, and the
> fact that they were "remotes/origin/foo" gave me an Aha! moment where I
> came to understand that the refs hierarchy is more flexible than just
> the conventions coded into git itself. I eventually felt free to create
> my own, private ref hierarchies.
>
> I am in no way opposed to this series. I just wanted to point out that
> there was some utility in those labels. It makes me think that it might
> be worthwhile for gitk to have a "raw-refs" mode, that shows the full
> "refs/foo/bar/baz" paths of all the heads, tags, and whatever else. It
> could be a useful teaching tool for git.
Yes, I understand that the longer names might be useful for beginners,
and the full names even more so. However, I think once a user has that
"aha!" moment, the space wasted on all the redundant words is a real
impediment to gitk's usability. It is common to have a few references on
a single commit (especially if you pull from multiple remotes), in which
case the summary line is completely invisible (and therefore its context
menu is unreachable). I don't like the idea of dumbing down the UI
permanently based on what users need at the very beginning of their Git
usage.
Would it be possible to use the short names in the UI but to add the
full names to a tooltip or to the context menu?
>> * Omit the "remote/" prefix on normal remote-tracking references. They
>
> If you re-roll, s:remote/:remotes/:.
Thanks.
>> are already distinguished via their two-tone rendering and (usually)
>> longer names, and this change saves a lot of visual clutter and
>> horizontal space.
>>
>> * Render remote-tracking references that have more than the usual
>> three slashes like
>>
>> origin/foo/bar
>> ^^^^^^^
>>
>> rather than
>>
>> origin/foo/bar (formerly remotes/origin/foo/bar)
>> ^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^
>>
>> , where the indicated part is the prefix that is rendered in a
>> different color. Usually, such a reference represents a remote
>> branch that contains a slash in its name, so the new split more
>> accurately portrays the separation between remote name and remote
>> branch name.
>
> *Love* this change! :)
>
>> * Introduce a separate constant to specify the background color used
>> for the branch name part of remote-tracking references, to allow it
>> to differ from the color used for local branches (which by default
>> is bright green).
>>
>> * Change the default background colors for remote-tracking branches to
>> light brown and brown (formerly they were pale orange and bright
>> green).
>
> Please don't change the remotebgcolor default.
>
> Also, perhaps the default remoterefbgcolor should be
> set remoterefbgcolor $headbgcolor
> ?
>
> I say this because when I applied the series, without the last patch, I
> was miffed that the remote/ref colour had changed.
This is a one-time inconvenience that gitk developers will experience. I
doubt that users jump backwards and forwards in gitk versions very often.
I do find it strange that gitk writes a color selection to its
configuration file *even if the user has left it at its default*.
Normally I would expect only user-changed settings to be written to the
config file, and other values to use the default that is built into the
program. For example, such an approach would have made the transition
from "green" to "lime" easier.
> [...]
Thanks for your feedback!
Michael
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references
2016-12-21 0:05 ` Michael Haggerty
@ 2016-12-21 19:07 ` Marc Branchaud
2016-12-22 8:15 ` Michael Haggerty
0 siblings, 1 reply; 24+ messages in thread
From: Marc Branchaud @ 2016-12-21 19:07 UTC (permalink / raw)
To: Michael Haggerty, Paul Mackerras; +Cc: git
On 2016-12-20 07:05 PM, Michael Haggerty wrote:
> On 12/20/2016 04:01 PM, Marc Branchaud wrote:
>> On 2016-12-19 11:44 AM, Michael Haggerty wrote:
>>> This patch series changes a bunch of details about how remote-tracking
>>> references are rendered in the commit list of gitk:
>>
>> Thanks for this! I like the new, compact look very much!
>>
>> That said, I remember when I was a new git user and I leaned heavily on
>> gitk to understand how references worked. It was particularly
>> illuminating to see the remote references distinctly labeled, and the
>> fact that they were "remotes/origin/foo" gave me an Aha! moment where I
>> came to understand that the refs hierarchy is more flexible than just
>> the conventions coded into git itself. I eventually felt free to create
>> my own, private ref hierarchies.
>>
>> I am in no way opposed to this series. I just wanted to point out that
>> there was some utility in those labels. It makes me think that it might
>> be worthwhile for gitk to have a "raw-refs" mode, that shows the full
>> "refs/foo/bar/baz" paths of all the heads, tags, and whatever else. It
>> could be a useful teaching tool for git.
>
> Yes, I understand that the longer names might be useful for beginners,
> and the full names even more so. However, I think once a user has that
> "aha!" moment, the space wasted on all the redundant words is a real
> impediment to gitk's usability. It is common to have a few references on
> a single commit (especially if you pull from multiple remotes), in which
> case the summary line is completely invisible (and therefore its context
> menu is unreachable). I don't like the idea of dumbing down the UI
> permanently based on what users need at the very beginning of their Git
> usage.
I agree.
> Would it be possible to use the short names in the UI but to add the
> full names to a tooltip or to the context menu?
I don't know -- my Tk-fu is weak.
>>> * Omit the "remote/" prefix on normal remote-tracking references. They
>>
>> If you re-roll, s:remote/:remotes/:.
>
> Thanks.
>
>>> are already distinguished via their two-tone rendering and (usually)
>>> longer names, and this change saves a lot of visual clutter and
>>> horizontal space.
>>>
>>> * Render remote-tracking references that have more than the usual
>>> three slashes like
>>>
>>> origin/foo/bar
>>> ^^^^^^^
>>>
>>> rather than
>>>
>>> origin/foo/bar (formerly remotes/origin/foo/bar)
>>> ^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^
>>>
>>> , where the indicated part is the prefix that is rendered in a
>>> different color. Usually, such a reference represents a remote
>>> branch that contains a slash in its name, so the new split more
>>> accurately portrays the separation between remote name and remote
>>> branch name.
>>
>> *Love* this change! :)
>>
>>> * Introduce a separate constant to specify the background color used
>>> for the branch name part of remote-tracking references, to allow it
>>> to differ from the color used for local branches (which by default
>>> is bright green).
>>>
>>> * Change the default background colors for remote-tracking branches to
>>> light brown and brown (formerly they were pale orange and bright
>>> green).
>>
>> Please don't change the remotebgcolor default.
>>
>> Also, perhaps the default remoterefbgcolor should be
>> set remoterefbgcolor $headbgcolor
>> ?
>>
>> I say this because when I applied the series, without the last patch, I
>> was miffed that the remote/ref colour had changed.
>
> This is a one-time inconvenience that gitk developers will experience. I
> doubt that users jump backwards and forwards in gitk versions very often.
In what way do you mean it's restricted to gitk developers?
Patch 12 introduces remoterefbgcolor, with a specific default value.
Prior to that, the "ref part" of remote refs was rendered with
headbgcolor. Users who changed their headbgcolor are used to seeing the
"ref part" of remote refs in the same color as their local heads.
Applying patch 12 changes the "ref part" color of remote refs, for such
users.
All I'm saying is that make the remoterefbgcolor default be $headbgcolor
avoids this.
But, honestly, I don't feel strongly about it.
M.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references
2016-12-21 19:07 ` Marc Branchaud
@ 2016-12-22 8:15 ` Michael Haggerty
2017-01-09 22:03 ` Marc Branchaud
0 siblings, 1 reply; 24+ messages in thread
From: Michael Haggerty @ 2016-12-22 8:15 UTC (permalink / raw)
To: Marc Branchaud, Paul Mackerras; +Cc: git
On 12/21/2016 08:07 PM, Marc Branchaud wrote:
> On 2016-12-20 07:05 PM, Michael Haggerty wrote:
>> On 12/20/2016 04:01 PM, Marc Branchaud wrote:
>>> [...]
>>> Please don't change the remotebgcolor default.
>>>
>>> Also, perhaps the default remoterefbgcolor should be
>>> set remoterefbgcolor $headbgcolor
>>> ?
>>>
>>> I say this because when I applied the series, without the last patch, I
>>> was miffed that the remote/ref colour had changed.
>>
>> This is a one-time inconvenience that gitk developers will experience. I
>> doubt that users jump backwards and forwards in gitk versions very often.
>
> In what way do you mean it's restricted to gitk developers?
Maybe I misunderstood your objection.
While developing this, I realized that the very first time your run gitk
(i.e., when you don't already have a configuration file), it writes the
then-current default colors into your configuration file. If you later
switch gitk versions to a version with different default colors, the
colors from the first-run version are preserved (unless the names of the
variables used to hold the colors are changed).
So if you would run the tip version of my branch first, then the parent
of that version, you would continue to see the colors as modified by the
final commit. If you then switch to the master version, the remote
branch names go back to green (because it goes back to using
`headbgcolor` again), but the remote prefix stays light brown. I thought
you were unhappy about some form of this unexpected persistence problem.
But this problem will mostly be experienced by gitk developers who jump
back and forth between versions.
A normal user probably mostly moves forward through version numbers, and
only occasionally. Such a user, jumping from master to the tip of my
branch (assuming they haven't customized anything), would see
* local branches stay lime
* remote branch prefixes stay pale orange (they don't change to light
brown because the pale orange color from master is stored in their
configuration file)
* remote branch names change from lime to brown (because the
`remoterefbgcolor` configuration setting didn't exist before)
> Patch 12 introduces remoterefbgcolor, with a specific default value.
> Prior to that, the "ref part" of remote refs was rendered with
> headbgcolor. Users who changed their headbgcolor are used to seeing the
> "ref part" of remote refs in the same color as their local heads.
> Applying patch 12 changes the "ref part" color of remote refs, for such
> users.
>
> All I'm saying is that make the remoterefbgcolor default be $headbgcolor
> avoids this.
For somebody who thinks that most people will want local and
remote-tracking branch names to be rendered in the same color, your
suggestion would be an improvement.
But for somebody like me who thinks it is a good idea to render
remote-tracking branch names in a different color than local branch
names, this is a feature, not a bug. Even a user who explicitly
configured `headbgcolor` to, say, purple, wasn't necessarily expressing
a wish to have remote-tracking branch names rendered in purple. Until
now they had no choice to set these colors separately!
So even for somebody who configured this setting before, I think that
having the remote-tracking branch names change color when the user
upgrades to this version is a good thing, because it lets the user know
that these two things can now be colored independently. If they don't
like the new default brown color, such a user knows where to change it
(even to make it agree with `headbgcolor` if they want that).
But I understand that this is a matter of personal preference. I have
but one "vote" :-)
Michael
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references
2016-12-22 8:15 ` Michael Haggerty
@ 2017-01-09 22:03 ` Marc Branchaud
0 siblings, 0 replies; 24+ messages in thread
From: Marc Branchaud @ 2017-01-09 22:03 UTC (permalink / raw)
To: Michael Haggerty, Paul Mackerras; +Cc: git
On 2016-12-22 03:15 AM, Michael Haggerty wrote:
> On 12/21/2016 08:07 PM, Marc Branchaud wrote:
>> On 2016-12-20 07:05 PM, Michael Haggerty wrote:
>>> On 12/20/2016 04:01 PM, Marc Branchaud wrote:
>>>> [...]
>>>> Please don't change the remotebgcolor default.
>>>>
>>>> Also, perhaps the default remoterefbgcolor should be
>>>> set remoterefbgcolor $headbgcolor
>>>> ?
>>>>
>>>> I say this because when I applied the series, without the last patch, I
>>>> was miffed that the remote/ref colour had changed.
>>>
>>> This is a one-time inconvenience that gitk developers will experience. I
>>> doubt that users jump backwards and forwards in gitk versions very often.
>>
>> In what way do you mean it's restricted to gitk developers?
>
> Maybe I misunderstood your objection.
>
> While developing this, I realized that the very first time your run gitk
> (i.e., when you don't already have a configuration file), it writes the
> then-current default colors into your configuration file. If you later
> switch gitk versions to a version with different default colors, the
> colors from the first-run version are preserved (unless the names of the
> variables used to hold the colors are changed).
>
> So if you would run the tip version of my branch first, then the parent
> of that version, you would continue to see the colors as modified by the
> final commit. If you then switch to the master version, the remote
> branch names go back to green (because it goes back to using
> `headbgcolor` again), but the remote prefix stays light brown. I thought
> you were unhappy about some form of this unexpected persistence problem.
> But this problem will mostly be experienced by gitk developers who jump
> back and forth between versions.
>
> A normal user probably mostly moves forward through version numbers, and
> only occasionally. Such a user, jumping from master to the tip of my
> branch (assuming they haven't customized anything), would see
>
> * local branches stay lime
> * remote branch prefixes stay pale orange (they don't change to light
> brown because the pale orange color from master is stored in their
> configuration file)
> * remote branch names change from lime to brown (because the
> `remoterefbgcolor` configuration setting didn't exist before)
>
>> Patch 12 introduces remoterefbgcolor, with a specific default value.
>> Prior to that, the "ref part" of remote refs was rendered with
>> headbgcolor. Users who changed their headbgcolor are used to seeing the
>> "ref part" of remote refs in the same color as their local heads.
>> Applying patch 12 changes the "ref part" color of remote refs, for such
>> users.
>>
>> All I'm saying is that make the remoterefbgcolor default be $headbgcolor
>> avoids this.
>
> For somebody who thinks that most people will want local and
> remote-tracking branch names to be rendered in the same color, your
> suggestion would be an improvement.
>
> But for somebody like me who thinks it is a good idea to render
> remote-tracking branch names in a different color than local branch
> names, this is a feature, not a bug. Even a user who explicitly
> configured `headbgcolor` to, say, purple, wasn't necessarily expressing
> a wish to have remote-tracking branch names rendered in purple. Until
> now they had no choice to set these colors separately!
>
> So even for somebody who configured this setting before, I think that
> having the remote-tracking branch names change color when the user
> upgrades to this version is a good thing, because it lets the user know
> that these two things can now be colored independently. If they don't
> like the new default brown color, such a user knows where to change it
> (even to make it agree with `headbgcolor` if they want that).
>
> But I understand that this is a matter of personal preference. I have
> but one "vote" :-)
I think we understand each other, and that we disagree. I don't feel
strongly about it though, so if you want to go this way that's fine by me.
Your case would be helped if the various ref colours were exposed in the
preferences dialog. Someone who upgrades to your gitk and doesn't like
the default remoterefbgcolor has to track down the right setting, close
all running gitk instances, and hand-edit ~/.gitk.
But I think improving gitk's colour-preferences dialog is a bit beyond
the scope of your topic...
M.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references
2016-12-19 16:44 [PATCH 00/13] gitk: tweak rendering of remote-tracking references Michael Haggerty
` (14 preceding siblings ...)
2016-12-20 15:01 ` Marc Branchaud
@ 2017-02-06 17:13 ` Marc Branchaud
15 siblings, 0 replies; 24+ messages in thread
From: Marc Branchaud @ 2017-02-06 17:13 UTC (permalink / raw)
To: Michael Haggerty, Paul Mackerras; +Cc: git
On 2016-12-19 11:44 AM, Michael Haggerty wrote:
> This patch series changes a bunch of details about how remote-tracking
> references are rendered in the commit list of gitk:
I don't see this series in git v2.12.0-rc0, nor in Paul's gitk repo.
I hope this is an oversight, and not that the series got dropped for
some reason.
M.
> * Omit the "remote/" prefix on normal remote-tracking references. They
> are already distinguished via their two-tone rendering and (usually)
> longer names, and this change saves a lot of visual clutter and
> horizontal space.
>
> * Render remote-tracking references that have more than the usual
> three slashes like
>
> origin/foo/bar
> ^^^^^^^
>
> rather than
>
> origin/foo/bar (formerly remotes/origin/foo/bar)
> ^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^
>
> , where the indicated part is the prefix that is rendered in a
> different color. Usually, such a reference represents a remote
> branch that contains a slash in its name, so the new split more
> accurately portrays the separation between remote name and remote
> branch name.
>
> * Introduce a separate constant to specify the background color used
> for the branch name part of remote-tracking references, to allow it
> to differ from the color used for local branches (which by default
> is bright green).
>
> * Change the default background colors for remote-tracking branches to
> light brown and brown (formerly they were pale orange and bright
> green).
>
> I understand that the colors of pixels on computer screens is an even
> more emotional topic that that of bikesheds, so I implemented the last
> change as a separate commit, the last one in the series. Feel free to
> drop it if you don't want the default color change.
>
> Along the way, I did a bunch of refactoring in the area to make these
> changes easier, and introduced a constant for the background color of
> "other" references so that it can also be adjusted by users.
>
> (Unfortunately, these colors can only be adjusted by editing the
> configuration file. Someday it would be nice to allow them to be
> configured via the preferences dialog.)
>
> It's been a while since I've written any Tcl code, so I apologize in
> advance for any howlers :-)
>
> This branch applies against the `master` branch in
> git://ozlabs.org/~paulus/gitk.
>
> Michael
>
> Michael Haggerty (13):
> gitk: when processing tag labels, don't use `marks` as scratch space
> gitk: keep track of tag types in a separate `types` array
> gitk: use a type "tags" to indicate abbreviated tags
> gitk: use a type "mainhead" to indicate the main HEAD branch
> gitk: fill in `wvals` as the tags are first processed
> gitk: simplify regexp
> gitk: extract a method `remotereftext`
> gitk: only change the color of the "remote" part of remote refs
> gitk: shorten labels displayed for modern remote-tracking refs
> gitk: use type "remote" for remote-tracking references
> gitk: introduce a constant otherrefbgcolor
> gitk: add a configuration setting `remoterefbgcolor`
> gitk: change the default colors for remote-tracking references
>
> gitk | 114 ++++++++++++++++++++++++++++++++++++++++++++-----------------------
> 1 file changed, 76 insertions(+), 38 deletions(-)
>
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2017-02-06 17:13 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-12-19 16:44 [PATCH 00/13] gitk: tweak rendering of remote-tracking references Michael Haggerty
2016-12-19 16:45 ` [PATCH 01/13] gitk: when processing tag labels, don't use `marks` as scratch space Michael Haggerty
2016-12-19 16:45 ` [PATCH 02/13] gitk: keep track of tag types in a separate `types` array Michael Haggerty
2016-12-19 16:45 ` [PATCH 03/13] gitk: use a type "tags" to indicate abbreviated tags Michael Haggerty
2016-12-19 16:45 ` [PATCH 04/13] gitk: use a type "mainhead" to indicate the main HEAD branch Michael Haggerty
2016-12-19 16:45 ` [PATCH 05/13] gitk: fill in `wvals` as the tags are first processed Michael Haggerty
2016-12-19 16:45 ` [PATCH 06/13] gitk: simplify regexp Michael Haggerty
2016-12-19 16:45 ` [PATCH 07/13] gitk: extract a method `remotereftext` Michael Haggerty
2016-12-19 16:45 ` [PATCH 08/13] gitk: only change the color of the "remote" part of remote refs Michael Haggerty
2016-12-19 16:45 ` [PATCH 09/13] gitk: shorten labels displayed for modern remote-tracking refs Michael Haggerty
2016-12-19 16:45 ` [PATCH 10/13] gitk: use type "remote" for remote-tracking references Michael Haggerty
2016-12-19 16:45 ` [PATCH 11/13] gitk: introduce a constant otherrefbgcolor Michael Haggerty
2016-12-19 16:45 ` [PATCH 12/13] gitk: add a configuration setting `remoterefbgcolor` Michael Haggerty
2016-12-19 16:45 ` [PATCH 13/13] gitk: change the default colors for remote-tracking references Michael Haggerty
2016-12-19 22:53 ` [PATCH 00/13] gitk: tweak rendering of " Philip Oakley
2016-12-20 8:03 ` Michael Haggerty
2016-12-20 15:01 ` Marc Branchaud
2016-12-20 22:17 ` Paul Mackerras
2016-12-20 22:53 ` Marc Branchaud
2016-12-21 0:05 ` Michael Haggerty
2016-12-21 19:07 ` Marc Branchaud
2016-12-22 8:15 ` Michael Haggerty
2017-01-09 22:03 ` Marc Branchaud
2017-02-06 17:13 ` Marc Branchaud
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.