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

Add NO_COLOR support #89

Merged
merged 2 commits into from
Feb 6, 2021
Merged

Add NO_COLOR support #89

merged 2 commits into from
Feb 6, 2021

Conversation

lambdagolem
Copy link
Contributor

The NO_COLOR variable appears to be a bit of a standard variable for handling this. See https://no-color.org/. termcolor also supports this https://docs.rs/termcolor/1.1.2/i686-unknown-linux-gnu/termcolor/enum.ColorChoice.html.

@pksunkara pksunkara merged commit b3dfd17 into console-rs:master Feb 6, 2021
@mitsuhiko
Copy link
Collaborator

This is the wrong way to do it. Color detection is done by clicolors-control which accidentally was removed. Reverting this.

mitsuhiko added a commit that referenced this pull request Feb 7, 2021
@lambdagolem
Copy link
Contributor Author

Sorry for the trouble but I was told in #88 that clicolors-control was no longer in use so I thought that this would be OK. Sorry again for the inconvenience!

@mitsuhiko
Copy link
Collaborator

@lambdagolem yeah. we're going to revert this. See #91

dtolnay pushed a commit to dtolnay-contrib/console that referenced this pull request Feb 4, 2022
…s#89)

This branch replaces the "kind" column in the tasks list view with a new
"state" column that indicates whether the task is currently running,
idle, or terminated. The "kind" column was initially intended to
distinguish between Tokio's blocking tasks and async tasks, but the
task's fields column also conveys this information, so the "kind" column
was really just useful for indicating whether the task was active or
terminated. Distinguishing vs sleeping and idle tasks here makes this
column somewhat more useful.

The task list can also be sorted by the state column. We may want to
consider making this the default sorting in the future...

This currently uses the Unicode "play", "pause", and "stop" symbols, as
proposed in console-rs#25, to display the different task states. In a subsequent
change, I'll add support for detecting and determining whether UTF-8 is
supported by the terminal.

![image](https://user-images.githubusercontent.com/2796466/129458704-a5643d93-6fe1-492f-aafe-6f70a8338b78.png)

Signed-off-by: Eliza Weisman <[email protected]>
dtolnay pushed a commit to dtolnay-contrib/console that referenced this pull request Feb 4, 2022
Depends on console-rs#88 
Depends on console-rs#89 

This branch builds on the CLI flags added in console-rs#88 to also add support for
disabling the use of non-ASCII characters in the console. The console
will now attempt to detect whether the terminal supports UTF-8 by
inspecting the `LANG` environment variable. If the value ends with
`UTF-8`, unicode characters will be used. If it does not, the console
will run in an ASCII-only mode. Furthermore, the CLI now includes a
`--lang` flag to override the value of the `LANG` environment variable,
and a `--ascii-only` flag to force the ASCII-only mode.

When Unicode support is disabled, we do the following:
- replace the "play", "pause", and "stop" characters added in console-rs#89 with
  `>`, `:` and `!`, respectively. I'm open to suggestions, if anyone
  can think of better ASCII characters to represent the "running",
  "idle", and "completed" states.
- the use of Unicode characters for the left, right, up, and down arrow
  keys, enter key, and escape key in the controls list is replaced with
  simply spelling out the names of those keys.
- the use of Unicode box-drawing characters in the task details window
  is avoided by disabling borders entirely. It would be nice to
  eventually replace this with ASCII art borders, but TUI doesn't have
  a way to provide a custom character set for borders, as far as I can
  tell.
- the Unicode micro symbol (mu) in microsecond durations is replaced
  with `u`, for `us`.
- the poll time histogram is disabled entirely, since TUI's sparklines
  rely on Unicode block characters.

This was implemented by changing the `view::Colors` struct, which
determines what colors are enabled based on the configuration, to
`view::Styles`, and making it also responsible for determining what
character set is enabled. It now is responsible for determining how to
style more UI elements.

### Screenshots:

```console
$ cargo run
```

Task list:

![image](https://user-images.githubusercontent.com/2796466/129485918-0421ae73-4104-446c-89cd-7f1266e75fb2.png)

Task details:

![image](https://user-images.githubusercontent.com/2796466/129485929-31106520-5676-4ec9-8aae-b13b831c1686.png)

```console
$ cargo run -- --ascii-only
```

Task list:

![image](https://user-images.githubusercontent.com/2796466/129485971-de66611e-10ac-4325-9bd3-27aaafdf8cd8.png)

Task details:

![image](https://user-images.githubusercontent.com/2796466/129486005-5c964369-adeb-4b62-b7cc-8dd96044e53c.png)

### Future Work

- Handle cases where `LANG` includes other Unicode character sets
  (e.g. UTF-16)?
- Also use `LANG` and other locale env variables for localization.
  Right now, we only look at the last part of the `LANG` variable,
  which determines the character set, but the first part of it
  determines the locale (e.g. on my machine, `LANG=en_US.UTF-8`).
  Doing proper localizations is likely to be a big pile of work,
  though, just in terms of actually translating text into languages
  other than English. There are probably existing libraries that
  could be used for the 'mechanical' parts (actually switching UI
  text), but the translations kind of inherently require human
  intervention...
- Use ASCII art borders when Unicode is disabled?
- Figure out an acceptable way to draw the histograms without
  Unicode characters? This may not really be possible...

Signed-off-by: Eliza Weisman <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants