{"thread":{"id":"64789","subject":"[PATCH] gitk: use config settings for head/tag colors","startedAt":"2026-01-13T06:28:44Z","lastAt":"2026-01-20T16:02:53Z","messageCount":3,"participants":["Shannon Barber via GitGitGadget","Johannes Sixt"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"533704","messageId":"pull.2030.git.1768285721660.gitgitgadget@gmail.com","threadId":"64789","inReplyTo":null,"subject":"[PATCH] gitk: use config settings for head/tag colors","fromName":"Shannon Barber via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2026-01-13T06:28:41Z","receivedAt":"2026-01-13T06:28:44Z","isPatch":true,"sender":{"key":"name:Shannon Barber","avatar":null},"body":"From: Shannon Barber <sbarber@dataspeedinc.com>\n\nThe drawtags procedure currently uses headfgcolor for all label text,\n ignoring the tagfgcolor setting.\n\nThe call to create the outline polygon for (non-tag) heads currently\n has the color for headoutlinecolor hardcoded to black.\n\nThis patch maintains the variables for the non-tag refs so that heads\n are colored differently from non-head (non-tag) refs.\n\nThe outline and fill colors for the non-head refs remain hardcoded to\n the prior values, black & #ddddff.\n\nSigned-off-by: Shannon Barber <sgbarber@gmail.com>\n---\n    gitk: use headoutlinecolor, headbgcolor, and tagfgcolor config settings\n    to change the color of the tags and head outlines and fill\n    \n    This patch makes the config settings, headoutlinecolor and tagfgcolor,\n    work. These are existing config settings but not used in the code.\n    \n    (I noticed that tagfgcolor was not working while making an extension for\n    vscode that exports its color theme to gitk.) (Upon review of the code I\n    found that headoutlinecolor was also not used and investigated and fixed\n    it.)\n    \n    This simple patch has them affect the target UI elements while drawing\n    refs and their outlined boxes. Tags are drawn in their own code branch\n    then heads and non-heads are drawn in another one. Because both head and\n    non-head refs are drawn in the same loop the colors used to draw (and\n    fill) toggle between the head colors and (still hard-coded) non-head ref\n    colors.\n    \n    Image showing it working, reviewing the patch that made it work.\n    gitk-colors\n    [https://github.com/user-attachments/assets/0eea207d-0891-41c8-8c6d-1464a96a1c76]\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-2030%2FMagmaiKH%2Fsbarber%2Fuse_color_config_variables-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2030/MagmaiKH/sbarber/use_color_config_variables-v1\nPull-Request: https://github.com/gitgitgadget/git/pull/2030\n\n gitk-git/gitk | 11 +++++++----\n 1 file changed, 7 insertions(+), 4 deletions(-)\n\ndiff --git a/gitk-git/gitk b/gitk-git/gitk\nindex 7f62c8041d..0415abd873 100755\n--- a/gitk-git/gitk\n+++ b/gitk-git/gitk\n@@ -6831,16 +6831,18 @@ proc drawtags {id x xt y1} {\n         } else {\n             # draw a head or other ref\n             if {[incr nheads -1] >= 0} {\n-                set col $headbgcolor\n+                set refoutlinecol $headoutlinecolor\n+                set reffillcol $headbgcolor\n                 if {$tag eq $mainhead} {\n                     set font mainfontbold\n                 }\n             } else {\n-                set col \"#ddddff\"\n+                set refoutlinecol black\n+                set reffillcol \"#ddddff\"\n             }\n             set xl [expr {$xl - $delta/2}]\n             $canv create polygon $x $yt $xr $yt $xr $yb $x $yb \\\n-                -width 1 -outline black -fill $col -tags tag.$id\n+                -width 1 -outline $refoutlinecol -fill $reffillcol -tags tag.$id\n             if {[regexp {^(remotes/.*/|remotes/)} $tag match remoteprefix]} {\n                 set rwid [font measure mainfont $remoteprefix]\n                 set xi [expr {$x + 1}]\n@@ -6850,7 +6852,8 @@ proc drawtags {id x xt y1} {\n                         -width 0 -fill $remotebgcolor -tags tag.$id\n             }\n         }\n-        set t [$canv create text $xl $y1 -anchor w -text $tag -fill $headfgcolor \\\n+        set textfgcolor [expr {$ntags >= 0 ? $tagfgcolor : $headfgcolor}]\n+        set t [$canv create text $xl $y1 -anchor w -text $tag -fill $textfgcolor \\\n                    -font $font -tags [list tag.$id text]]\n         if {$ntags >= 0} {\n             $canv bind $t <1> $tagclick\n\nbase-commit: d529f3a197364881746f558e5652f0236131eb86\n-- \ngitgitgadget\n"},{"id":"533861","messageId":"f55a85a0-fb57-4911-bd60-cf863da5436c@kdbg.org","threadId":"64789","inReplyTo":"pull.2030.git.1768285721660.gitgitgadget@gmail.com","subject":"Re: [PATCH] gitk: use config settings for head/tag colors","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2026-01-14T18:11:23Z","receivedAt":"2026-01-14T18:11:27Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Thank you for your contribution!\n\nAm 13.01.26 um 07:28 schrieb Shannon Barber via GitGitGadget:\n> From: Shannon Barber <sbarber@dataspeedinc.com>\n> \n> The drawtags procedure currently uses headfgcolor for all label text,\n>  ignoring the tagfgcolor setting.\n> \n> The call to create the outline polygon for (non-tag) heads currently\n>  has the color for headoutlinecolor hardcoded to black.\n> \n> This patch maintains the variables for the non-tag refs so that heads\n>  are colored differently from non-head (non-tag) refs.\n> \n> The outline and fill colors for the non-head refs remain hardcoded to\n>  the prior values, black & #ddddff.\n> \n> Signed-off-by: Shannon Barber <sgbarber@gmail.com>\n\nIn this project, the author and signer-off should be identical. Please\nchoose one identity for both.\n\nIt was very hard to figure out what the patch attempts to do. The commit\nmessage wasn't very helpful, I am afraid. I would have appreciated if a\nshort summary of the status quo at a high level had been given. For example:\n\n--- 8< ---\nGitk draws ref names with 4 different styles depending on the type of ref:\n\n  - ...\n  ...\n\nThe styles use variables that can be set in the configuration file for\n..., but hard-codes the style for ... But there do exist configuration\nentries for ... but they are not used. Replace the hard-coded values for\nthese latter ones, but leave the remaining styles unchanged.\n\n...\n--- 8< ---\n\nWhat is also missing is what the implications for users are after the\nchange. Clearly, the settings stored in the configuration file are now\nheeded. But what happens for users who are unaware that there are\nsettings (since they are not accessible via the UI). Are any observable\nchanges intentional? If yes, what is the possible impact?\n\nBTW, the paragraph indentation is a bit odd.\n\nThe patch text looks good.\n\n-- Hannes\n\n"},{"id":"534268","messageId":"509acce4-d1d0-4c18-8c42-7ebe84594a92@kdbg.org","threadId":"64789","inReplyTo":"SJ1SPRMB0003BF77E3500DF7C96E3042D18CA@SJ1SPRMB0003.namprd20.prod.outlook.com","subject":"Re: [PATCH] gitk: use config settings for head/tag colors","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2026-01-20T16:02:49Z","receivedAt":"2026-01-20T16:02:53Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 15.01.26 um 07:03 schrieb Shannon Barber:\n> I think I can simplify it to :\n>>  gitk: honor the headoutlinecolor and tagfgcolor config settings\n> I pushed a fix with a corrected sign-off.\n> \n> These settings already exist but the code ignored them.\n> \n> I do not understand your question about a high-level summary.\n> There are no structural changes.\n> There are no functional changes.\n> This is a cosmetic change to how the head and tag refs are drawn, to use\n> already existing color configurations (that were inadvertently ignored.)\n\nWhile the effect of the change is just cosmetic (in the sense that the\nvisual appearance of the graph labels is changed), it is not a \"no\nfunctional change\".\n\nConsider a user who has experimented with the configuration file. They\nmay have found that changing the value of these variables in the file\ndoesn't work, and then forgot about it, leaving the modified value in\nthe file. With this change, the value that was so far ignored, now\nsuddenly has an effect. It is worthwhile to analyze such behavior and\ndocument it at least in the commit message, so that later readers of the\ncode and history know that the case was considered.\n\nYou should think about such effects and note them in the commit message.\nInclude the expected behavior in such edge cases. That's what I meant by\n high-level summary.\n\n-- Hannes\n\n"}]}