Skip to content

Conversation

@cbrnr
Copy link
Contributor

@cbrnr cbrnr commented Oct 30, 2025

Summary

Improve readability of progress bars by drawing the right portions in dimmed black instead of dimmed green. This makes it much easier to distinguish from the left (finished) part, which is drawn in green.

Fixes #6908.

Test Plan

Tested locally, looks as follows:

white black

@konstin konstin requested a review from zanieb October 30, 2025 10:33
@konstin konstin added the enhancement New feature or improvement to existing functionality label Oct 30, 2025
@zanieb
Copy link
Member

zanieb commented Oct 30, 2025

Funny, this doesn't change anything with my terminal color scheme :)

@zanieb zanieb enabled auto-merge (squash) October 30, 2025 14:04
@zanieb zanieb merged commit c7aaa8b into astral-sh:main Oct 30, 2025
188 of 189 checks passed
@cbrnr cbrnr deleted the progressbars branch October 30, 2025 14:27
@eliegoudout
Copy link

Isn't it more likely to have users with dimm black terminal (Who would have worse readability then) than users with dimm Green terminal?
Just a thought.

@cbrnr
Copy link
Contributor Author

cbrnr commented Oct 31, 2025

Readability is also improved with dark background, see my screenshot. The point is that you see the actual progress, not so much the unfinished bars to the right.

@eliegoudout
Copy link

Readability is also improved with dark background, see my screenshot.

The dark mode is not universal and many people have different "dark mode" terminal color. My point is that it may be that some users may have the exact color you used as a background color, making them lose readability. Of course, people may also have "dark green" background (in which case, the previous colors would be worse), but my point is that the latter is less likely than the former, isn't it?

My point only stands if the internals define a hardcoded color though, I don't know if it's the case?

@eliegoudout
Copy link

Just so you know, here's the situation locally on my side on a PowrShell (I don't really use that, but people may)

Previous version
image
Your improved version
image

As you can see, previous version was bad, and your version is better, but still shows complete black for incomplete part. In this case, it's still a win, but if the former version was working well (with an actual dark green), then your update would be a regression on my side.

@cbrnr
Copy link
Contributor Author

cbrnr commented Oct 31, 2025

@eliegoudout don't you think this is clearly better? This change is intentional, you can actually see the progress, whereas previously, I can see only one single green bar. I get it that on some terminals with black background, dimmed black might be pure black, but since it is clear where the 100% mark is, you can still see the progress (because the green color wasn't changed at all, it is just better visible now). Or do you have to see the unfinished (remaining) part of the bar (and if so why)?

@cbrnr
Copy link
Contributor Author

cbrnr commented Oct 31, 2025

I think this also heavily depends on the terminal you are using. Which one is it?

tmeijn pushed a commit to tmeijn/dotfiles that referenced this pull request Nov 3, 2025
This MR contains the following updates:

| Package | Update | Change |
|---|---|---|
| [astral-sh/uv](https://github.com/astral-sh/uv) | patch | `0.9.5` -> `0.9.7` |

MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot).

**Proposed changes to behavior should be submitted there as MRs.**

---

### Release Notes

<details>
<summary>astral-sh/uv (astral-sh/uv)</summary>

### [`v0.9.7`](https://github.com/astral-sh/uv/blob/HEAD/CHANGELOG.md#097)

[Compare Source](astral-sh/uv@0.9.6...0.9.7)

Released on 2025-10-30.

##### Enhancements

- Add Windows x86-32 emulation support to interpreter architecture checks ([#&#8203;13475](astral-sh/uv#13475))
- Improve readability of progress bars ([#&#8203;16509](astral-sh/uv#16509))
- Add GitHub attestations for uv release artifacts ([#&#8203;11357](astral-sh/uv#11357))

##### Bug fixes

- Drop terminal coloring from `uv auth token` output ([#&#8203;16504](astral-sh/uv#16504))
- Don't use UV\_LOCKED to enable `--check` flag ([#&#8203;16521](astral-sh/uv#16521))

### [`v0.9.6`](https://github.com/astral-sh/uv/blob/HEAD/CHANGELOG.md#096)

[Compare Source](astral-sh/uv@0.9.5...0.9.6)

Released on 2025-10-29.

This release contains an upgrade to Astral's fork of `async_zip`, which addresses potential sources of ZIP parsing differentials between uv and other Python packaging tooling. See [GHSA-pqhf-p39g-3x64](GHSA-pqhf-p39g-3x64) for additional details.

##### Security

- Address ZIP parsing differentials ([GHSA-pqhf-p39g-3x64](GHSA-pqhf-p39g-3x64))

##### Python

- Upgrade GraalPy to 25.0.1 ([#&#8203;16401](astral-sh/uv#16401))

##### Enhancements

- Add `--clear` to `uv build` to remove old build artifacts ([#&#8203;16371](astral-sh/uv#16371))
- Add `--no-create-gitignore` to `uv build` ([#&#8203;16369](astral-sh/uv#16369))
- Do not error when a virtual environment directory cannot be removed due to a busy error ([#&#8203;16394](astral-sh/uv#16394))
- Improve hint on `pip install --system` when externally managed ([#&#8203;16392](astral-sh/uv#16392))
- Running `uv lock --check` with outdated lockfile will print that `--check` was passed, instead of `--locked`  ([#&#8203;16322](astral-sh/uv#16322))
- Update `uv init` template for Maturin ([#&#8203;16449](astral-sh/uv#16449))
- Improve ordering of Python sources in logs ([#&#8203;16463](astral-sh/uv#16463))
- Restore DockerHub release images and annotations ([#&#8203;16441](astral-sh/uv#16441))

##### Bug fixes

- Check for matching Python implementation during `uv python upgrade` ([#&#8203;16420](astral-sh/uv#16420))
- Deterministically order `--find-links` distributions ([#&#8203;16446](astral-sh/uv#16446))
- Don't panic in `uv export --frozen` when the lockfile is outdated ([#&#8203;16407](astral-sh/uv#16407))
- Fix root of `uv tree` when `--package` is used with circular dependencies ([#&#8203;15908](astral-sh/uv#15908))
- Show package list with `pip freeze --quiet` ([#&#8203;16491](astral-sh/uv#16491))
- Limit `uv auth login pyx.dev` retries to 60s ([#&#8203;16498](astral-sh/uv#16498))
- Add an empty group with `uv add --group ... -r ...` ([#&#8203;16490](astral-sh/uv#16490))

##### Documentation

- Update docs for maturin build backend init template ([#&#8203;16469](astral-sh/uv#16469))
- Update docs to reflect previous changes to signal forwarding semantics ([#&#8203;16430](astral-sh/uv#16430))
- Add instructions for installing via MacPorts ([#&#8203;16039](astral-sh/uv#16039))

</details>

---

### Configuration

📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.

♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 **Ignore**: Close this MR and you won't be reminded about this update again.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box

---

This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS4xNjkuMSIsInVwZGF0ZWRJblZlciI6IjQxLjE2OS4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJSZW5vdmF0ZSBCb3QiXX0=-->
@eliegoudout
Copy link

eliegoudout commented Nov 3, 2025

don't you think this is clearly better?

First of all, yes! On the screens I provided, the new version is clearly better. But I tink this is only because my console does not show the correct colors for the first version (dimmed green), no?

I would have liked to see the rendering for your console before your PR.

My point is simply that previously, since the colors were green vs dimmed green, there was almost no risk of a user having the dimmed green badly displayed. However, with the new version (green vs dimmed black), there is a greater risk or users having a "conflict of colors" with their own console background.

Honestly, I think it's just splitting hairs at this point, but I was simply sharing my (very mild) concern :)


I think this also heavily depends on the terminal you are using. Which one is it?

The default (i think) Windows PowerShell terminal

@cbrnr
Copy link
Contributor Author

cbrnr commented Nov 3, 2025

No worries, I think it is good to discuss any regressions!

I would have liked to see the rendering for your console before your PR.

I posted it here. This was the intended look, and it was really hard to distinguish the two green colors.

My point is simply that previously, since the colors were green vs dimmed green, there was almost no risk of a user having the dimmed green badly displayed. However, with the new version (green vs dimmed black), there is a greater risk or users having a "conflict of colors" with their own console background.

True, but even if a dark (dimmed black) background makes the right portion of the bar invisible now, the progress is still clearly visible. So even this special case is an improvement vs. the previous green/dimmed green IMO.

The default (i think) Windows PowerShell terminal

It looks like special (Unicode?) characters are not working either for you. I recommend Windows Terminal (and not Command Prompt aka cmd.exe) on Windows; this should fix both the colors and the Unicode issues.

@eliegoudout
Copy link

eliegoudout commented Nov 3, 2025

Thanks for your answer! Indeed, the previous renders your showed are pretty bad! And you're right that even if the incomplete part is invisible, it's still better than the terrible rendering from before.

I mean, we could argue for ages about the perfect color(s), but at least, seing the previous rendering, I agree that there is no regression at all.

All the best!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or improvement to existing functionality

Projects

None yet

Development

Successfully merging this pull request may close these issues.

light background terminal: low constrast progress bars

4 participants