Opened 10 years ago

Closed 7 years ago

#4494 closed bug (fixed)

[Terminal] some default color settings are hard to read

Reported by: scottmc Owned by: leavengood
Priority: normal Milestone: R1
Component: Applications/Terminal Version: R1/alpha1
Keywords: gci2011 Cc: prasadjoshi124@…
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by scottmc)

Blue text with a green highlight background is just plain hard to read. Perhaps this can be defaulted to a better color combination. See screenshot.

Attachments (7)

terminal-ls-colors.png (10.5 KB ) - added by scottmc 10 years ago.
results from running ls in terminal, showing an almost unreadable color combo
.dircolors (4.1 KB ) - added by humdinger 10 years ago.
blue-on-green -> black-on-green
0001-Change-color-scheme-for-other-writable-directory.patch (2.9 KB ) - added by Prasad 7 years ago.
ls_color_ow.png (155.7 KB ) - added by Prasad 7 years ago.
0001-Change-color-scheme-for-other-writable-directory.2.patch (3.4 KB ) - added by Prasad 7 years ago.
0001-Change-color-scheme-for-other-writable-directory.3.patch (3.4 KB ) - added by Prasad 7 years ago.
0001-Change-color-scheme-for-other-writable-directory.4.patch (4.2 KB ) - added by Prasad 7 years ago.

Download all attachments as: .zip

Change History (31)

by scottmc, 10 years ago

Attachment: terminal-ls-colors.png added

results from running ls in terminal, showing an almost unreadable color combo

comment:1 by scottmc, 10 years ago

Summary: [Terminal] some default color settings are hard to hard[Terminal] some default color settings are hard to read

comment:2 by jackburton, 10 years ago

We are using the same default colors as the Gnome terminal. They are hard to read there too. With a black background, they look much better, though.

in reply to:  2 comment:3 by jackburton, 10 years ago

Replying to jackburton:

We are using the same default colors as the Gnome terminal. They are hard to read there too. With a black background, they look much better, though.

Just to be clear: I'm not saying that since it looks bad in Gnome, too, it's okay. Just that we're following some sort of standard, and that the colors have to be checked with different backgrounds (at least black, and white). BTW a black background makes much more sense (even by default, IMO), since it's less flashy and more readable.

comment:4 by scottmc, 10 years ago

Description: modified (diff)

If you look at the screenshot I posted, you'll see the issue is the green chars with a blue highlight background. I'm not so sure that that becomes easier to read if you change the white background to black though. Where can this color combo even be adjusted? I couldn't locate it in any of the menus.

comment:5 by axeld, 10 years ago

The colors itself are fine, it's just the combination that "ls --color" uses that should be adapted. Green on blue just can't look good in any case :-)

comment:6 by humdinger, 10 years ago

dircolors -p > /boot/system/etc/.dircolors

produces a list of the used default colors. I have looked for blue-on-green (34;42) which was only found for STICKY_OTHER_WRITABLE and changed that to black-on-green (30;42).

Putting

eval `dircolors -b /boot/system/etc/.dircolors`

into /boot/system/etc/profile should load these new color on every Terminal start. I couldn't test, because I couldn't find anything that was blue-on-green to begin with. I attached the slightly altered .dircolors. Maybe someone has another itch to scratch and modifies a few more entries before committing it together with the changes to the profile.

by humdinger, 10 years ago

Attachment: .dircolors added

blue-on-green -> black-on-green

comment:7 by pepol, 8 years ago

Keywords: gci2011 added

The problem was checked during GCI 2011. It still looks the same with default settings on hrev43238. Also (for someone who doesn't know these things...), these colors are used for 777 chmod-ed directories.

comment:8 by Prasad, 7 years ago

Has a Patch: set

comment:9 by Prasad, 7 years ago

Cc: prasadjoshi124@… added

by Prasad, 7 years ago

Attachment: ls_color_ow.png added

comment:10 by korli, 7 years ago

Hi Prasad,

it seems your patch doesn't include changes for src/dircolors.hin. Could you please add this and update the patch? Thanks.

comment:11 by korli, 7 years ago

I forgot to write: a comment header in colorls.sh would be nice too:)

in reply to:  10 ; comment:12 by Prasad, 7 years ago

Replying to korli:

Hi Prasad,

it seems your patch doesn't include changes for src/dircolors.hin. Could you please add this and update the patch? Thanks.

I am not sure I understand you correctly, but seems like the latest diff in dircolrs.hin is already reflected in the latest source code

~> echo $LS_COLORS | tr -s ':' '\n' | grep -i lz
*.lzh=01;31
*.lzma=01;31
*.tlz=01;31
*.lz=01;31

~> echo $LS_COLORS | tr -s ':' '\n' | grep -i cgm
*.cgm=01;35

~> echo $LS_COLORS | tr -s ':' '\n' | grep -i emf
*.emf=01;35

The latest commit for dircolors.hin shows

commit 9904bec57614b6d4aee9a50344435fada6dcf1ee
diff --git a/src/bin/coreutils/src/dircolors.hin b/src/bin/coreutils/src/dircolors.hin
index 91ddcb6..6a4b1e3 100644
--- a/src/bin/coreutils/src/dircolors.hin
+++ b/src/bin/coreutils/src/dircolors.hin
@@ -1,8 +1,7 @@
 # Configuration file for dircolors, a utility to help you set the
 # LS_COLORS environment variable used by GNU ls with the --color option.
 
-# Copyright (C) 1996, 1999-2009
-# Free Software Foundation, Inc.
+# Copyright (C) 1996, 1999-2010 Free Software Foundation, Inc.
 # Copying and distribution of this file, with or without modification,
 # are permitted provided the copyright notice and this notice are preserved.
 
@@ -116,6 +115,7 @@ EXEC 01;32
 .Z   01;31
 .dz  01;31
 .gz  01;31
+.lz  01;31
 .xz  01;31
 .bz2 01;31
 .bz  01;31
@@ -175,6 +175,8 @@ EXEC 01;32
 .xcf 01;35
 .xwd 01;35
 .yuv 01;35
+.cgm 01;35
+.emf 01;35
 
 # http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions
 .axv 01;35

in reply to:  11 comment:13 by Prasad, 7 years ago

Replying to korli:

I forgot to write: a comment header in colorls.sh would be nice too:)

I will attach another patch

comment:14 by Prasad, 7 years ago

Added a patch https://dev.haiku-os.org/attachment/ticket/4494/0001-Change-color-scheme-for-other-writable-directory.2.patch

The patch adds additional comments in the colors.sh file.

in reply to:  12 ; comment:15 by korli, 7 years ago

Replying to Prasad:

it seems your patch doesn't include changes for src/dircolors.hin. Could you please add this and update the patch? Thanks.

I am not sure I understand you correctly, but seems like the latest diff in dircolrs.hin is already reflected in the latest source code

Your patch modifies dircolors.h which is a generated file based on dircolors.hin. Thus your modification of dircolors.h might be lost anytime dircolors.h is regenerated (or coreutils is updated or outsourced). It should take place at line 83 if I'm not mistaken.

in reply to:  15 comment:16 by Prasad, 7 years ago

Replying to korli:

Replying to Prasad:

it seems your patch doesn't include changes for src/dircolors.hin. Could you please add this and update the patch? Thanks.

I am not sure I understand you correctly, but seems like the latest diff in dircolrs.hin is already reflected in the latest source code

Your patch modifies dircolors.h which is a generated file based on dircolors.hin. Thus your modification of dircolors.h might be lost anytime dircolors.h is regenerated (or coreutils is updated or outsourced). It should take place at line 83 if I'm not mistaken.

Thanks I was not aware of the fact dircolors.h is auto-generated. I have attached another patch [https://dev.haiku-os.org/attachment/ticket/4494/0001-Change-color-scheme-for-other-writable-directory.4.patch ] please check if it is suitable.

However, I am not able to figure out the reason for committing the dircolors.h in the repository. Since it is auto-generated, it could have been generated while building the source itself.

comment:17 by diver, 7 years ago

Has a Patch: unset

Prasad, could you take a look at #1944 as well?

in reply to:  17 ; comment:18 by Prasad, 7 years ago

Replying to diver:

Since I am new here, I would like to know the reason the patch has been removed. Does this mean it is included in the mainline? or Is the patch not working on your machine? Please educate.

Prasad, could you take a look at #1944 as well?

Thanks Diver I will have a look.

Regards, Prasad

in reply to:  18 ; comment:19 by luroh, 7 years ago

Since I am new here, I would like to know the reason the patch has been removed.

The missing patch flag is simply a bug that was triggered by diver adding his comment. A few days ago, Trac was upgraded and we are experiencing some fallout. This particular bug is being tracked in #9058.

in reply to:  19 comment:20 by Prasad, 7 years ago

Replying to luroh:

Since I am new here, I would like to know the reason the patch has been removed.

The missing patch flag is simply a bug that was triggered by diver adding his comment. A few days ago, Trac was upgraded and we are experiencing some fallout. This particular bug is being tracked in #9058.

oops, thanks a lot for clarification.

I wish this patch would be applied soon so that I no longer have to track it.

comment:21 by leavengood, 7 years ago

Owner: changed from jackburton to leavengood
Status: newassigned

I will try to apply this patch tonight, probably 6 to 8 hours from when this comment was left.

in reply to:  21 comment:22 by Prasad, 7 years ago

Replying to leavengood:

I will try to apply this patch tonight, probably 6 to 8 hours from when this comment was left.

Can this be applied today?

comment:23 by korli, 7 years ago

Applied in hrev44712

comment:24 by kallisti5, 7 years ago

Resolution: fixed
Status: assignedclosed

picked for R1A4

Tested as ok, going to close for now. Feel free to re-open if any issues still exist.

Note: See TracTickets for help on using tickets.