Re: [PATCH v2] gitk: Add a horizontal scrollbar for commit history
On 13-10-31 05:05 AM, Paul Mackerras wrote: On Wed, Oct 30, 2013 at 01:47:08PM +0100, Nicolas Cornu wrote: This is useful on all our repos, every times, as we put a tag per day. If the HEAD didn't move during 150 days, we got 150 tags. Here is a patch that I did some time ago but have never pushed out. Do you think it is an improvement when using gitk on a repo with lots of tags? I like this a lot! Thanks for putting it together. I think it's worth releasing this as-is. My only wish is that it be generalized for any kind of ref: Each refs/* namespace should form a distinct display category. For example, given refs like this (note the non-standard builds namespace): refs/heads/maint refs/heads/master refs/heads/next refs/remotes/origin/maint refs/remotes/origin/master refs/remotes/origin/next refs/remotes/origin/pu refs/tags/v1.1.1 refs/tags/v2.2.2 refs/tags/v3.3.3 refs/tags/v4.4.4 refs/builds/1.1.1-1 refs/builds/1.1.1-2 refs/builds/1.1.1-3 refs/builds/1.1.1-4 refs/builds/1.1.1-5 And let's say that somehow all these refs refer to the same commit that's being displayed in gitk, then I'd like to see something like: [3 branches...][4 remote refs...][4 tags...][5 builds...] Gitk can be smart about how it displays standard namespaces (as it already is for tags, heads, remote heads, etc.), but for non-standard namespaces gitk can just display the namespace's name directly. M. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] gitk: Add a horizontal scrollbar for commit history
Hi, Am 31.10.2013 10:05, schrieb Paul Mackerras: On Wed, Oct 30, 2013 at 01:47:08PM +0100, Nicolas Cornu wrote: This is useful on all our repos, every times, as we put a tag per day. If the HEAD didn't move during 150 days, we got 150 tags. Here is a patch that I did some time ago but have never pushed out. Do you think it is an improvement when using gitk on a repo with lots of tags? Paul. [PATCH] gitk: Tag display improvements When a commit has many tags, the tag icons in the graph display can easily become so wide as to push the commit message off the right-hand edge of the graph display pane. This changes the display so that if there are more than 3 tags or they would take up more than a quarter of the width of the pane, we instead display a single tag icon with a legend inside it like 4 tags If the user clicks on the tag icon, gitk then displays all the tags in the diff display pane. Signed-off-by: Paul Mackerras pau...@samba.org Yes please. I have not tried it but the description sounds great. Will try to give it a testdrive next week. Cheers Heiko -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] gitk: Add a horizontal scrollbar for commit history
On Wed, Oct 30, 2013 at 01:47:08PM +0100, Nicolas Cornu wrote:
This is useful on all our repos, every times, as we put a tag per day.
If the HEAD didn't move during 150 days, we got 150 tags.
Here is a patch that I did some time ago but have never pushed out.
Do you think it is an improvement when using gitk on a repo with lots
of tags?
Paul.
[PATCH] gitk: Tag display improvements
When a commit has many tags, the tag icons in the graph display can
easily become so wide as to push the commit message off the right-hand
edge of the graph display pane. This changes the display so that if
there are more than 3 tags or they would take up more than a quarter
of the width of the pane, we instead display a single tag icon with
a legend inside it like 4 tags If the user clicks on the tag
icon, gitk then displays all the tags in the diff display pane.
Signed-off-by: Paul Mackerras pau...@samba.org
---
gitk | 96 ++--
1 file changed, 83 insertions(+), 13 deletions(-)
diff --git a/gitk b/gitk
index 5cd00d8..0bdb146 100755
--- a/gitk
+++ b/gitk
@@ -2385,6 +2385,7 @@ proc makewindow {} {
$ctext tag conf found -back $foundbgcolor
$ctext tag conf currentsearchhit -back $currentsearchhitbgcolor
$ctext tag conf wwrap -wrap word
+$ctext tag conf bold -font textfontbold
.pwbottom add .bleft
if {!$use_ttk} {
@@ -6387,6 +6388,25 @@ proc bindline {t id} {
$canv bind $t Button-1 lineclick %x %y $id 1
}
+proc graph_pane_width {} {
+global use_ttk
+
+if {$use_ttk} {
+ set g [.tf.histframe.pwclist sashpos 0]
+} else {
+ set g [.tf.histframe.pwclist sash coord 0]
+}
+return [lindex $g 0]
+}
+
+proc totalwidth {l font extra} {
+set tot 0
+foreach str $l {
+ set tot [expr {$tot + [font measure $font $str] + $extra}]
+}
+return $tot
+}
+
proc drawtags {id x xt y1} {
global idtags idheads idotherrefs mainhead
global linespc lthickness
@@ -6398,9 +6418,27 @@ proc drawtags {id x xt y1} {
set marks {}
set ntags 0
set nheads 0
+set singletag 0
+set maxtags 3
+set maxtagpct 25
+set maxwidth [expr {[graph_pane_width] * $maxtagpct / 100}]
+set delta [expr {int(0.5 * ($linespc - $lthickness))}]
+set extra [expr {$delta + $lthickness + $linespc}]
+
if {[info exists idtags($id)]} {
set marks $idtags($id)
set ntags [llength $marks]
+ if {$ntags $maxtags ||
+ [totalwidth $marks mainfont $extra] $maxwidth} {
+ # show just a single n tags... tag
+ set singletag 1
+ if {$ntags == 1} {
+ set marks [list tag...]
+ } else {
+ set marks [list [format %d tags... $ntags]]
+ }
+ set ntags 1
+ }
}
if {[info exists idheads($id)]} {
set marks [concat $marks $idheads($id)]
@@ -6413,7 +6451,6 @@ proc drawtags {id x xt y1} {
return $xt
}
-set delta [expr {int(0.5 * ($linespc - $lthickness))}]
set yt [expr {$y1 - 0.5 * $linespc}]
set yb [expr {$yt + $linespc - 1}]
set xvals {}
@@ -6428,7 +6465,7 @@ proc drawtags {id x xt y1} {
}
lappend xvals $xt
lappend wvals $wid
- set xt [expr {$xt + $delta + $wid + $lthickness + $linespc}]
+ set xt [expr {$xt + $wid + $extra}]
}
set t [$canv create line $x $y1 [lindex $xvals end] $y1 \
-width $lthickness -fill $reflinecolor -tags tag.$id]
@@ -6444,7 +6481,12 @@ proc drawtags {id x xt y1} {
$xr $yt $xr $yb $xl $yb $x [expr {$yb - $delta}] \
-width 1 -outline $tagoutlinecolor -fill $tagbgcolor \
-tags tag.$id]
- $canv bind $t 1 [list showtag $tag_quoted 1]
+ if {$singletag} {
+ set tagclick [list showtags $id 1]
+ } else {
+ set tagclick [list showtag $tag_quoted 1]
+ }
+ $canv bind $t 1 $tagclick
set rowtextx([rowofcommit $id]) [expr {$xr + $linespc}]
} else {
# draw a head or other ref
@@ -6471,7 +6513,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 {$ntags = 0} {
- $canv bind $t 1 [list showtag $tag_quoted 1]
+ $canv bind $t 1 $tagclick
} elseif {$nheads = 0} {
$canv bind $t $ctxbut [list headmenu %X %Y $id $tag_quoted]
}
@@ -10878,6 +10920,23 @@ proc listrefs {id} {
return [list $x $y $z]
}
+proc add_tag_ctext {tag} {
+global ctext cached_tagcontent tagids
+
+if {![info exists cached_tagcontent($tag)]} {
+ catch {
+ set cached_tagcontent($tag) [exec git cat-file -p $tag]
+ }
+}
+$ctext insert end [mc Tag]: $tag\n bold
+if {[info exists
Re: [PATCH v2] gitk: Add a horizontal scrollbar for commit history
Am 10/30/2013 11:58, schrieb Nicolas Cornu: This scrollbar is not optional and is useful if there is a lot of tags or branches. If this is the only case where the scrollbar is useful, i.e., it would be handy only once every other week, then it is better to remember that you can pan around in the window by moving the mouse with the middle mouse button held down. Vertical screen estate in the commit history pane is too precious to waste for a scrollbar that is useless most of the time. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] gitk: Add a horizontal scrollbar for commit history
This is useful on all our repos, every times, as we put a tag per day. If the HEAD didn't move during 150 days, we got 150 tags. So, it depends, maybe can I put it as an option in Edit Preferences? 2013/10/30 Johannes Sixt j.s...@viscovery.net: Am 10/30/2013 11:58, schrieb Nicolas Cornu: This scrollbar is not optional and is useful if there is a lot of tags or branches. If this is the only case where the scrollbar is useful, i.e., it would be handy only once every other week, then it is better to remember that you can pan around in the window by moving the mouse with the middle mouse button held down. Vertical screen estate in the commit history pane is too precious to waste for a scrollbar that is useless most of the time. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] gitk: Add a horizontal scrollbar for commit history
On 13-10-30 08:47 AM, Nicolas Cornu wrote: This is useful on all our repos, every times, as we put a tag per day. If the HEAD didn't move during 150 days, we got 150 tags. So, it depends, maybe can I put it as an option in Edit Preferences? Eek, even with a scrollbar, 150 tags seems like a lot to pan over. I've often thought it would be good for gitk to combine multiple ref names into some kind of dropdown or view-on-hover list. (I don't know anything about Tcl/Tk, so I don't know what's feasible.) So if a commit has more than a couple of branches (and/or tags), only show the first branch name along with a glyph indicating that there are more, and let the user click on (or hover over) that glyph to see all the branches (or tags -- that is, still keep the tags and branches displayed separately). M. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] gitk: Add a horizontal scrollbar for commit history
2013/10/30 Marc Branchaud marcn...@xiplink.com: On 13-10-30 08:47 AM, Nicolas Cornu wrote: This is useful on all our repos, every times, as we put a tag per day. If the HEAD didn't move during 150 days, we got 150 tags. So, it depends, maybe can I put it as an option in Edit Preferences? Eek, even with a scrollbar, 150 tags seems like a lot to pan over. Now, it works pretty well and is easier than mouse middle-click which acts strangely for me. I've often thought it would be good for gitk to combine multiple ref names into some kind of dropdown or view-on-hover list. (I don't know anything about Tcl/Tk, so I don't know what's feasible.) So if a commit has more than a couple of branches (and/or tags), only show the first branch name along with a glyph indicating that there are more, and let the user click on (or hover over) that glyph to see all the branches (or tags -- that is, still keep the tags and branches displayed separately). It doesn't change that if you got 150 tags, when you will show them up, you will need to scroll. M. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] gitk: Add a horizontal scrollbar for commit history
On 13-10-30 10:49 AM, Nicolas Cornu wrote: 2013/10/30 Marc Branchaud marcn...@xiplink.com: On 13-10-30 08:47 AM, Nicolas Cornu wrote: This is useful on all our repos, every times, as we put a tag per day. If the HEAD didn't move during 150 days, we got 150 tags. So, it depends, maybe can I put it as an option in Edit Preferences? Eek, even with a scrollbar, 150 tags seems like a lot to pan over. Now, it works pretty well and is easier than mouse middle-click which acts strangely for me. Yes, it's a bit weird for me too. I think it's because the middle-button-dragging can only be horizontal *xor* vertical. I've often thought it would be good for gitk to combine multiple ref names into some kind of dropdown or view-on-hover list. (I don't know anything about Tcl/Tk, so I don't know what's feasible.) So if a commit has more than a couple of branches (and/or tags), only show the first branch name along with a glyph indicating that there are more, and let the user click on (or hover over) that glyph to see all the branches (or tags -- that is, still keep the tags and branches displayed separately). It doesn't change that if you got 150 tags, when you will show them up, you will need to scroll. True, but it would mean that there's no horizontal scroll bar taking up space in the main display. The scrolling would also vertically oriented, which is mousewheel-friendly. Also, the display would be a lot less cluttered. M. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
