Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stronger terminal colors #5444

Open
eysi09 opened this issue Nov 20, 2023 · 8 comments
Open

Stronger terminal colors #5444

eysi09 opened this issue Nov 20, 2023 · 8 comments
Assignees
Labels
devex Developer experience and ease of use. discussion feature request

Comments

@eysi09
Copy link
Collaborator

eysi09 commented Nov 20, 2023

We've been consolidating all the different places we render ANSI colors to the terminal to make it easier to update the colors we use in one place.

Right now our primary color is chalk.grey and judging by internal conversations we mostly agree that it's too light.

On transparent terminals it's practically impossible to read.

The obvious first choice would be to just go for chalk.white but I'm wondering if we want to find some middleground and use some specific hex color. Note that chalk will down sample it to work with any terminal, even those that only support 16 colors. So we should basically find something that down samples to white.

This ticket is meant as a discussion and I'd love to get feedback from the more design oriented folks on the team as well as our community.

To get us started, I'll share some examples below:

Using primary: chalk.grey on a transparent terminal 👇

Screenshot 2023-11-20 at 13 56 23

Using primary: chalk.grey on an opaque terminal 👇

Screenshot 2023-11-20 at 13 57 38

Using primary: chalk.white 👇

Screenshot 2023-11-20 at 13 58 26

Using primary: chalk.hex("#a6a1c7") 👇

Screenshot 2023-11-20 at 13 59 38

We can also play around with other colors. Here's warning: chalk.yellow 👇

Screenshot 2023-11-20 at 14 00 59

Here's warning: chalk.hex("#FFA500") 👇

Screenshot 2023-11-20 at 14 02 02

We could do the same for secondary | success | error styles.

Anyway, just wanted to see if you all had thoughts on this. Otherwise I'd suggest sticking with what we have but changing our primary color from chalk.grey to chalk.white.

@eysi09 eysi09 added feature request discussion devex Developer experience and ease of use. labels Nov 20, 2023
@shumailxyz
Copy link
Contributor

shumailxyz commented Nov 20, 2023

A side note:

With this, I suggest to also consider adding an option to disable colored output altogether and show everything in white (or dark for light terminal).

@eysi09 eysi09 self-assigned this Nov 20, 2023
@eysi09
Copy link
Collaborator Author

eysi09 commented Nov 20, 2023

Good point.

You can already do that though with the FORCE_COLOR env var which chalk respects.

See: https://github.com/chalk/chalk#supportscolor

For example:

Screenshot 2023-11-20 at 15 30 26

This needs to be documented though and made possible via the CLI.

@eysi09
Copy link
Collaborator Author

eysi09 commented Nov 20, 2023

Added an FAQ entry here: #5448

@stefreak
Copy link
Member

I think the behaviour proposed in this comment is reasonable: #2420 (comment)

Basically the proposal is to follow the NO_COLOR standard defined in https://no-color.org/

@eysi09
Copy link
Collaborator Author

eysi09 commented Nov 20, 2023

You can. See e.g. my screenshot above.

@stefreak
Copy link
Member

stefreak commented Nov 20, 2023

I know you can using FORCE_COLOR=0; The proposal in the comment is to support the NO_COLOR standard like many other CLI tools. I don't want to start the discussion here because it is unrelated to the color theme itself, but I wanted to reference the existing issue #2420 and specifically that comment, as supporting that standard would make Garden behave like many other CLI tools.

@eysi09
Copy link
Collaborator Author

eysi09 commented Nov 20, 2023

Oh whoops 🤦‍♂️

I just saw _COLOR and read it as the same. My bad.

I fully agree and I'll fix this.

@eysi09
Copy link
Collaborator Author

eysi09 commented Nov 20, 2023

I think the behaviour proposed in this comment is reasonable: #2420 (comment)

Fixed in #5451

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
devex Developer experience and ease of use. discussion feature request
Projects
None yet
Development

No branches or pull requests

3 participants