gitk: make color preferences visually more pleasing and better usable

[j6t]

I find the user interface to set the color preferences a bit ugly for these reasons:

• The color samples are not clickable as one would expect who enters the dialog. Instead, the description is the button that must be clicked.

• Since the descriptive texts are different for the preferences, the width of the buttons are different, too.

• The descriptions themselves are not always natural language (read: they are nerdy) and use abbreviations.

This series makes the descriptions static text and turns the color samples into the clickable buttons. It also makes the descriptions and dialog titles more natural language.

This is the dialog before the change:

And this is the dialog after the change:

cc: mark mlevedahl@gmail.com

[j6t]

/submit

[gitgitgadget]

Error: git --git-dir=pr-repo.git fetch --no-tags https://github.com/gitgitgadget/git/ -- +refs/notes/gitgitgadget:refs/notes/gitgitgadget +refs/heads/maint:refs/remotes/upstream/maint +refs/heads/seen:refs/remotes/upstream/seen +refs/heads/master:refs/remotes/upstream/master +refs/heads/next:refs/remotes/upstream/next +refs/pull/2194/head:refs/pull/2194/head +refs/pull/2194/merge:refs/pull/2194/merge failed: 128,
fatal: couldn't find remote ref refs/pull/2194/merge

[j6t]

Hmm, these patches are sourced directly from j6t/gitk/pull/48, so the edits lack the gitk-git/ prefix. Is anything special needed to handle this in Gitgitgadget?

[dscho]

Is anything special needed to handle this in Gitgitgadget?

Yes, I think we also need to mirror gitk/master in addition to git-gui/master, then...

[dscho]

@j6t I re-ran the workflow run that wanted to handle your /submit.

[gitgitgadget]

Error: Unrecognized project

[dscho]

Error: Unrecognized project

That's what I feared. There's special logic in GitGitGadget for Git GUI... And none yet for gitk.

[dscho]

There's special logic in GitGitGadget for Git GUI... And none yet for gitk.

See https://github.com/gitgitgadget/gitgitgadget/blob/cadedf4eec007b3798f61e825af876cc7adc09ba/lib/project-options.ts#L27-L31

[j6t]

@dscho What if I just rewrite the branch by cherry-picking the commits into the git code? The branch here would be abandoned once I merge my original PR in the gitk repository, but at least I should be able to use Gitgitgadget as the ML gateway.

[dscho]

That would make for a fine stop-gap solution.

[j6t]

/submit

[gitgitgadget]

Submitted as pull.2194.git.1785998419.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-2194/j6t/gitk-prefs-color-buttons-v1

To fetch this version to local tag pr-2194/j6t/gitk-prefs-color-buttons-v1:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-2194/j6t/gitk-prefs-color-buttons-v1

[gitgitgadget]

mark wrote on the Git mailing list (how to reply to this email):

On 8/6/26 2:40 AM, Johannes Sixt via GitGitGadget wrote:
> From: Johannes Sixt <j6t@kdbg.org>
> 
> After the user has selected a color in the Preferences dialog, the
> helper proc prefspage_set_colorswatches is used update the colors shown
> in the Preferences dialog. Use this proc also after the Preferences
> dialog is constructed to show the initial colors. This keeps the
> procedure that gives the UI elements their colors in a single place.
> 
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
This completes collecting the color settings to one place, Good!

[gitgitgadget]

User mark <mlevedahl@gmail.com> has been added to the cc: list.

[gitgitgadget]

mark wrote on the Git mailing list (how to reply to this email):

On 8/6/26 2:40 AM, Johannes Sixt via GitGitGadget wrote:
> From: Johannes Sixt <j6t@kdbg.org>
> 
> The color selection elements in the Preferences dialog are set up in a
> very uniform manner. The code doing that has grown in the past by simply
> modifying a copy of a paragraph. Extract the varying parts into a list
> and then operate the repeating parts in a foreach loop. This helps a
> later change where we want to set up the UI elements in a different way.
> 
> Change the UI names "markbgsep" and "selbgsep" to drop the "sep", which
> has obviously been left over by accident when "hunksep" was copied.
> 
> Change the suffix "but" to "btn", which resonates a bit better when
> reading the code.
> 
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
>  gitk-git/gitk | 114 ++++++++++++++++++++++++--------------------------
>  1 file changed, 55 insertions(+), 59 deletions(-)
> 
> diff --git a/gitk-git/gitk b/gitk-git/gitk
> index f5eb963b86..137940defb 100755
> --- a/gitk-git/gitk
> +++ b/gitk-git/gitk
> @@ -11832,55 +11832,46 @@ proc prefspage_colors {notebook} {


> -
> -    label $page.linkfg -padx 40 -relief sunk
> -    ttk::button $page.linkfgbut -text [mc "Link"] \
> -        -command [list choosecolor linkfgcolor {} $page [mc "link"]]
> -    grid x $page.linkfgbut $page.linkfg -sticky w
> +
> +    set coloruielems [list \
> +        bg          bgcolor {} \
> +                    [mc "Background"] \
> +                    [mc "background"] \
> +        fg          fgcolor {} \
> +                    [mc "Foreground"] \
> +                    [mc "foreground"] \
The list is computed and used each time a dialog box is started from all static elements,
no real change. But this cleanly separates the per item data from the boiler plate,
definitely more readable. Good.

[gitgitgadget]

mark wrote on the Git mailing list (how to reply to this email):

On 8/6/26 2:40 AM, Johannes Sixt via GitGitGadget wrote:
> From: Johannes Sixt <j6t@kdbg.org>
> 
> When the user goes to the color preferences, the eye is automatically
> drawn to the color samples. However, clicking on the sample with the
> intent to change it does nothing. Instead, the text label also acts as
> a button and must be clicked to change the color.
> 
> Turn the color samples into clickable buttons and the text labels into
> static text. Use non-themed buttons because their color can be changed
> by simply specifying the color properties. (Themed buttons would need
> a lot more elaboration.)
> 
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
>  gitk-git/gitk | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/gitk-git/gitk b/gitk-git/gitk
> index 137940defb..877b2ad27f 100755
> --- a/gitk-git/gitk
> +++ b/gitk-git/gitk
> @@ -11867,10 +11867,10 @@ proc prefspage_colors {notebook} {
>      ]
>  
>      foreach {uielem colorvar idx label title} $coloruielems {
> -        label $page.$uielem -padx 40 -relief sunk
> -        ttk::button $page.${uielem}btn -text $label \
> +        ttk::label $page.$uielem -text $label
> +        button $page.${uielem}btn -padx 40 -pady 0 \
>              -command [list choosecolor $colorvar $idx $page $title]
> -        grid x $page.${uielem}btn $page.$uielem -sticky w
> +        grid x $page.$uielem $page.${uielem}btn -sticky w
>      }
>  
>      grid columnconfigure $page 2 -weight 1
> @@ -11896,7 +11896,7 @@ proc prefspage_set_colorswatches {page} {
>          linkfg    $linkfgcolor \
>      ]
>      foreach {uielem color} $coloruielems {
> -        $page.$uielem configure -background $color
> +        $page.${uielem}btn configure -background $color -activebackground $color
>      }
>  }
>  

The original approach has unthemed labels, allowing easy specification of color, and
themed buttons. With this change, the roles reverse, so swapping themed / unthemed makes
sense. Good.

But, the colored buttons do not stand out to my eye as much as in the prior approach.
Perhaps use -borderwidth 2? This is totally subjective, I'm ok if you leave this as-is.

[gitgitgadget]

Johannes Sixt wrote on the Git mailing list (how to reply to this email):

Am 07.08.26 um 16:37 schrieb mark:
> But, the colored buttons do not stand out to my eye as much as in the prior approach.
> Perhaps use -borderwidth 2?

I agree. -borderwith 2 does help emphasize that these are clickable
buttons. I'll also insert a small space between the buttons like this:

@@ -11868,9 +11868,9 @@ proc prefspage_colors {notebook} {
 
     foreach {uielem colorvar idx label title} $coloruielems {
         ttk::label $page.$uielem -text $label
-        button $page.${uielem}btn -padx 40 -pady 0 \
+        button $page.${uielem}btn -padx 40 -pady 0 -borderwidth 2 \
             -command [list choosecolor $colorvar $idx $page $title]
-        grid x $page.$uielem $page.${uielem}btn -sticky w
+        grid x $page.$uielem $page.${uielem}btn -sticky w -pady 1
     }
 
     grid columnconfigure $page 2 -weight 1


-- Hannes

[gitgitgadget]

mark wrote on the Git mailing list (how to reply to this email):

On 8/6/26 2:40 AM, Johannes Sixt via GitGitGadget wrote:
> From: Johannes Sixt <j6t@kdbg.org>
> 
> When the user clicks a color preference, a color selection dialog is
> presented whose title is provided in parts by the caller. The dialog
> implementation must supply the rest of the title. This is unfriendly
> for translations. Provide the full title by the caller. Rewrite the
> texts to be more natural language.
> 
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
>  gitk-git/gitk | 24 ++++++++++++------------
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/gitk-git/gitk b/gitk-git/gitk
> index 9e735d91bf..454f54dca8 100755
> --- a/gitk-git/gitk
> +++ b/gitk-git/gitk
> @@ -11836,34 +11836,34 @@ proc prefspage_colors {notebook} {
>      set coloruielems [list \
>          bg          bgcolor {} \
>                      [mc "Background"] \
> -                    [mc "background"] \
> +                    [mc "choose background color"] \
>          fg          fgcolor {} \
>                      [mc "Main text"] \
> -                    [mc "foreground"] \
> +                    [mc "choose main text color"] \

> @@ -12014,11 +12014,11 @@ proc choose_themeloader {prefspage} {
>      }
>  }
>  
> -proc choosecolor {v vi prefspage x} {
> +proc choosecolor {v vi prefspage title} {
>      global $v
>  
>      set c [tk_chooseColor -initialcolor [lindex [set $v] $vi] \
> -               -title [mc "Gitk: choose color for %s" $x]]
> +               -title "Gitk: $title"]
>      if {$c eq {}} return
>      lset $v $vi $c
>      set_gui_colors

This with the prior patch should help translation due to use of more common idioms and
complete phrases rather than jargon. Good.

[gitgitgadget]

Johannes Sixt wrote on the Git mailing list (how to reply to this email):

Am 07.08.26 um 16:37 schrieb mark:
> This with the prior patch should help translation due to use of more common idioms and
> complete phrases rather than jargon. Good.

"Complete phrases" and "jargon" are words I need for the commit
messages! Thank you :-)

Now, with a fresh eye, I see that we have text like this:

	Diff: old lines background

This looks more like an assemblement of words and jargon than a phrase
in natural language. Any suggestions for improvement? How about

	Background of old lines in diffs

Sounds a bit clumsy.

(In this case I prefer to say "diffs" rather than e.g. "patch text",
because we are looking at differences between versions, "diffs", and not
patches. Also, we already have "diff" in multiple other places in the UI.)

-- Hannes

[gitgitgadget]

Mark Levedahl wrote on the Git mailing list (how to reply to this email):

On 8/8/26 6:00 AM, Johannes Sixt wrote:
> Am 07.08.26 um 16:37 schrieb mark:
>> This with the prior patch should help translation due to use of more common idioms and
>> complete phrases rather than jargon. Good.
> "Complete phrases" and "jargon" are words I need for the commit
> messages! Thank you :-)
>
> Now, with a fresh eye, I see that we have text like this:
>
> 	Diff: old lines background
>
> This looks more like an assemblement of words and jargon than a phrase
> in natural language. Any suggestions for improvement? How about
>
> 	Background of old lines in diffs
>
> Sounds a bit clumsy.
>
> (In this case I prefer to say "diffs" rather than e.g. "patch text",
> because we are looking at differences between versions, "diffs", and not
> patches. Also, we already have "diff" in multiple other places in the UI.)
>
> -- Hannes
>

I'm ok with using "Diff" as a common identifier for this here. gitk is parsing commit
diffs from git, showing each hunk separately. I'd also rather not use patch. The UI
already shows "new version" and "old version", so using new lines and old lines is consistent.

But, one thing missing, hinted at by your suggestion "Background of ..." is that the clear
definition of what is being affected is poorly expressed. A complete description of each
item would require a paragraph, probably with an example image. Trying to compress into a
few words will always exploit context and presume some common language we expect a
git/gitk user to understand or be able to learn in context.

Maybe some extra words and categorization would help. Consider using a longer category
description to provide common information, for instance:

  -General Canvas Area
                           Background
       Marked Lines Background
                              Main Text
                        Selected Text
                              Link Text
    -Commit Differences
                          old line text
                        new line text
             -old line background
       etc.

etc, where the lines beginning with "-" are just separators and do not have an associated
color selection button.

Mark

Mark

[gitgitgadget]

Junio C Hamano wrote on the Git mailing list (how to reply to this email):

Johannes Sixt <j6t@kdbg.org> writes:

> 	Diff: old lines background
> 	Background of old lines in diffs
>
> Sounds a bit clumsy.

Both lacking "color" is not a problem because it is easy to see that
this entire thing is about "color" from the context (like these
appear in "Color" menu or something)?