threads / patch / 50593

patch, 2 partsgitk: refresh the colour scheme

Subject: [PATCH 1/2] gitk: refresh the colour scheme

## tl;dr

5 messages between Feb 26, 2019 and Feb 4, 2021. Diffs are folded; open one to read it.

replies: 4people: 2as markdown or json

Andrej Shadura· Feb 26, 2019, 11:05 UTC · lore

The colours gitk is currently using are from the basic 16 colour palette, and are a bit too intensive to be comfortable or pleasant to work with.

Adjust the main colours (commit nodes, remotes, tags and one branch colour) to be slightly softer.

Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk>
---
 gitk-git/gitk | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

Show changes to gitk-git/gitk +6 −6

diff --git a/gitk-git/gitk b/gitk-git/gitk
index a14d7a16b2..5766754ab6 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -12302,7 +12302,7 @@ if {[tk windowingsystem] eq "aqua"} {
     set extdifftool "meld"
 }
 
-set colors {"#00ff00" red blue magenta darkgrey brown orange}
+set colors {"#00ff00" red blue #f282f2 darkgrey brown orange}
 if {[tk windowingsystem] eq "win32"} {
     set uicolor SystemButtonFace
     set uifgcolor SystemButtonText
@@ -12325,11 +12325,11 @@ set ignorespace 0
 set worddiff ""
 set markbgcolor "#e0e0ff"
 
-set headbgcolor "#00ff00"
+set headbgcolor #98ff5e
 set headfgcolor black
 set headoutlinecolor black
-set remotebgcolor #ffddaa
-set tagbgcolor yellow
+set remotebgcolor #bae2ff
+set tagbgcolor #f3fb57
 set tagfgcolor black
 set tagoutlinecolor black
 set reflinecolor black
@@ -12338,10 +12338,10 @@ set filesepfgcolor black
 set linehoverbgcolor #ffff80
 set linehoverfgcolor black
 set linehoveroutlinecolor black
-set mainheadcirclecolor yellow
+set mainheadcirclecolor #ffeb74
 set workingfilescirclecolor red
 set indexcirclecolor "#00ff00"
-set circlecolors {white blue gray blue blue}
+set circlecolors {white #08b5ed gray blue blue}
 set linkfgcolor blue
 set circleoutlinecolor $fgcolor
 set foundbgcolor yellow

-- 
2.19.1

Andrej Shadura· Feb 26, 2019, 11:05 UTC · re: Andrej Shadura · lore

[PATCH 2/2] gitk: disable autoselect by default

Auto-selection of the commit hash overwrites whatever content was in the selection clipboard, and also pollutes the clipboard history if the user is using a clipboard manager. Most users probably want this off by default.

Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk>
---
 gitk-git/gitk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Show changes to gitk-git/gitk +1 −1

diff --git a/gitk-git/gitk b/gitk-git/gitk
index 5766754ab6..583e505709 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -12291,7 +12291,7 @@ set maxlinelen 200
 set showlocalchanges 1
 set limitdiffs 1
 set datetimeformat "%Y-%m-%d %H:%M:%S"
-set autoselect 1
+set autoselect 0
 set autosellen 40
 set perfile_attrs 0
 set want_ttk 1

-- 
2.19.1

Paul Mackerras· Mar 2, 2019, 23:02 UTC · re: Andrej Shadura · lore

Re: [PATCH 1/2] gitk: refresh the colour scheme

On Tue, Feb 26, 2019 at 12:05:34PM +0100, Andrej Shadura wrote:

Show 8 quoted lines

> The colours gitk is currently using are from the basic 16 colour
> palette, and are a bit too intensive to be comfortable or pleasant
> to work with.
> 
> Adjust the main colours (commit nodes, remotes, tags and one branch
> colour) to be slightly softer.
> 
> Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk>

Thanks for the patch, but I disagree. I do like the change you made to the tag colours, but the blue you have for the commit node circles is pretty blah. That needs a more definite colour.

Also, the "too intensive to be comfortable or pleasant" in the commit message reflect a personal preference, and the way it is put seems to me to be too intensive to be comfortable or pleasant.

Paul.

Andrej Shadura· Mar 4, 2019, 09:35 UTC · re: Paul Mackerras · lore

Re: [PATCH 1/2] gitk: refresh the colour scheme

On 03/03/2019 00:02, Paul Mackerras wrote:

Show 13 quoted lines

> On Tue, Feb 26, 2019 at 12:05:34PM +0100, Andrej Shadura wrote:
>> The colours gitk is currently using are from the basic 16 colour
>> palette, and are a bit too intensive to be comfortable or pleasant
>> to work with.
>>
>> Adjust the main colours (commit nodes, remotes, tags and one branch
>> colour) to be slightly softer.
>>
>> Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk>
> 
> Thanks for the patch, but I disagree.  I do like the change you made
> to the tag colours, but the blue you have for the commit node circles
> is pretty blah.  That needs a more definite colour.

I see.

1) Would you accept the patch without that change?
2) What colour would you prefer (except the already existing one)?

> Also, the "too intensive to be comfortable or pleasant" in the commit
> message reflect a personal preference, and the way it is put seems to
> me to be too intensive to be comfortable or pleasant.

Hmm, sorry if that came across not the way I intended. I was trying to formulate the thought in a way that would not be emotional or subjective, but I guess the end result was exactly opposite.

-- 
Cheers,
  Andrej

Andrej Shadura· Feb 4, 2021, 20:34 UTC · re: Andrej Shadura · lore

Re: [PATCH 1/2] gitk: refresh the colour scheme

Hi,

On 04/03/2019 10:35, Andrej Shadura wrote:

Show 19 quoted lines

> On 03/03/2019 00:02, Paul Mackerras wrote:
>> On Tue, Feb 26, 2019 at 12:05:34PM +0100, Andrej Shadura wrote:
>>> The colours gitk is currently using are from the basic 16 colour
>>> palette, and are a bit too intensive to be comfortable or pleasant
>>> to work with.
>>>
>>> Adjust the main colours (commit nodes, remotes, tags and one branch
>>> colour) to be slightly softer.
>>>
>>> Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk>
>>
>> Thanks for the patch, but I disagree.  I do like the change you made
>> to the tag colours, but the blue you have for the commit node circles
>> is pretty blah.  That needs a more definite colour.
> 
> I see.
> 
> 1) Would you accept the patch without that change?
> 2) What colour would you prefer (except the already existing one)?

Show 7 quoted lines

>> Also, the "too intensive to be comfortable or pleasant" in the commit
>> message reflect a personal preference, and the way it is put seems to
>> me to be too intensive to be comfortable or pleasant.
> 
> Hmm, sorry if that came across not the way I intended. I was trying to
> formulate the thought in a way that would not be emotional or
> subjective, but I guess the end result was exactly opposite.

I’d be happy to resubmit the patch adjusted to your preference, only if you gave me some more ideas on how you’d like to see it.

Thanks in advance.

-- 
Cheers,
  Andrej