From: Mark Levedahl <hidden> Date: 2016-06-15 22:43:18
Johannes Sixt wrote:
Is there a chance that we get Mark Levedahl's gitk patches into 1.5.3:
I found a bug in the highlight patch (the color picker updated the wrong
panel in the chooser but did set the correct color), and updated the
tab-stop patch to use a spin control to enforce entry of small integers
only. As there is possible interest, I am sending the amended series.
Mark
From: Mark Levedahl <hidden> Date: 2016-06-15 22:43:18
Cygwin's tk by default uses a very dark selection background color that
makes the currently selected text almost unreadable. On linux, the default
selection background is a light gray which is very usable. This makes the
default a light gray everywhere but allows the user to configure the
color as well.
Signed-off-by: Mark Levedahl <redacted>
---
gitk | 26 +++++++++++++++++++++++---
1 files changed, 23 insertions(+), 3 deletions(-)
@@ -402,7 +402,7 @@ proc makewindow {} { global rowctxmenu mergemax wrapcomment global highlight_files gdttype global searchstring sstring- global bgcolor fgcolor bglist fglist diffcolors+ global bgcolor fgcolor bglist fglist diffcolors selectbgcolor global headctxmenu menu .bar
@@ -5936,6 +5945,16 @@ proc choosecolor {v vi w x cmd} { eval $cmd $c }+proc setselbg {c} {+ global bglist cflist+ foreach w $bglist {+ $w configure -selectbackground $c+ }+ $cflist tag configure highlight \+ -background [$cflist cget -selectbackground]+ allcanvs itemconf secsel -fill $c+}+ proc setbg {c} { global bglist
@@ -6292,6 +6311,7 @@ set colors {green red blue magenta darkgrey brown orange} set bgcolor white set fgcolor black set diffcolors {red "#00a000" blue}+set selectbgcolor gray85 catch {source ~/.gitk}
From: Mark Levedahl <hidden> Date: 2016-06-15 22:43:18
When adjusting fontsize (using ctrl+/-), all panes except the lower right
were updated. This fixes that.
Signed-off-by: Mark Levedahl <redacted>
---
gitk | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
From: Mark Levedahl <hidden> Date: 2016-06-15 22:43:18
Not all projects use the convention that one tabstop = 8 characters, and
a common convention is to use one tabstop = on level of indent. For such
projects, using 8 characters per tabstop often shows too much whitespace
per indent. This allows the user to configure the number of characters
to use per tabstop.
Signed-off-by: Mark Levedahl <redacted>
---
gitk | 17 +++++++++++++----
1 files changed, 13 insertions(+), 4 deletions(-)
@@ -5852,7 +5855,7 @@ proc doprefs {} { global maxwidth maxgraphpct diffopts global oldprefs prefstop showneartags global bgcolor fgcolor ctext diffcolors selectbgcolor- global uifont+ global uifont tabstop set top .gitkprefs set prefstop $top
@@ -6296,6 +6304,7 @@ if {$tclencoding == {}} { set mainfont {Helvetica 9} set textfont {Courier 9} set uifont {Helvetica 9 bold}+set tabstop 8 set findmergefiles 0 set maxgraphpct 50 set maxwidth 16
From: Paul Mackerras <hidden> Date: 2016-06-15 22:43:18
Mark Levedahl writes:
I found a bug in the highlight patch (the color picker updated the wrong
panel in the chooser but did set the correct color), and updated the
tab-stop patch to use a spin control to enforce entry of small integers
only. As there is possible interest, I am sending the amended series.
Ah. I just pushed out a pile of patches to gitk.git including your
three. Could you do an incremental patch on top of that for me?
Thanks,
Paul.
From: Brian Downing <hidden> Date: 2016-06-15 22:43:18
Mark Levedahl wrote:
Cygwin's tk by default uses a very dark selection background color
that makes the currently selected text almost unreadable. On linux,
the default selection background is a light gray which is very usable.
This makes the default a light gray everywhere but allows the user to
configure the color as well.
I noticed this, and also noticed that the dark color in question was
in fact the default Windows selection background color. Unfortunately,
wish/gitk doesn't also use the default Windows selection foreground color
(white), so the result is pretty unreadable.
When playing with Git on Windows I worked around the problem by changing
the selection color system-wide.
(This patch is perhaps better than making it work the "Windows way"
with the right system foreground color, though, as the tag and branch
markers are also pretty ugly against a dark background...)
-bcd
--
*** Brian Downing [off-list ref]
From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:18
Paul Mackerras [off-list ref] writes:
Mark Levedahl writes:
quoted
I found a bug in the highlight patch (the color picker updated the wrong
panel in the chooser but did set the correct color), and updated the
tab-stop patch to use a spin control to enforce entry of small integers
only. As there is possible interest, I am sending the amended series.
Ah. I just pushed out a pile of patches to gitk.git including your
three. Could you do an incremental patch on top of that for me?
I took a look at differences between your gitk.git and what I
have. It appears that our "proc readrefs" differ a bit.
Most notably, the global hash tagcontents is read when readrefs
run in the version I have, while gitk.git version fills it
lazily in showtag, where it is actually used. Because you read
the refs using "show-ref -d", you do not need to do extra forks
to figure out the objects referred to by the tags in your code.
I think what you have is a lot better from interactive latency
point of view. I'll take the version from gitk.git and push the
results out.
From: Mark Levedahl <hidden> Date: 2016-06-15 22:43:18
The tabstop must be a smallish positive integer, and a spinbox is the
accepted UI control to accomplish this limiting rather than the text
entry box previously used.
Signed-off-by: Mark Levedahl <redacted>
---
gitk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
From: Mark Levedahl <hidden> Date: 2016-06-15 22:43:18
The callback function was incorrectly set to update the background
colorbar when updated the selection background. This did not affect the
colors chosen or their use, just their presentation in the preferences
dialog box.
Signed-off-by: Mark Levedahl <redacted>
---
gitk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
From: Paul Mackerras <hidden> Date: 2016-06-15 22:43:18
Junio C Hamano writes:
I took a look at differences between your gitk.git and what I
have. It appears that our "proc readrefs" differ a bit.
Most notably, the global hash tagcontents is read when readrefs
run in the version I have, while gitk.git version fills it
lazily in showtag, where it is actually used. Because you read
the refs using "show-ref -d", you do not need to do extra forks
to figure out the objects referred to by the tags in your code.
Yes, that was one of the many improvements I made. Basically I pulled
a lot of stuff over from the 'new' branch.
I think what you have is a lot better from interactive latency
point of view. I'll take the version from gitk.git and push the
results out.
Thanks. I have now pushed out Mark Levedahl's two bug fixes as well.
Paul.