-
-
Notifications
You must be signed in to change notification settings - Fork 55
Description
Is there an existing request for this?
- I have searched the existing issues
Is your feature request related to a problem?
The progress bar (e.g. when copying large amounts of data) moves in whole characters.
With the use of Unicode characters around U+2589 and U+1FB87 we could make it move by 1/8th of a character.
(apt changed its progress bar like this in Ubuntu 25.04 or 25.10-ish.)
Care should be taken to verify the handling of right-to-left scrollbar (when Options -> Configuration -> Classic progressbar is disabled, and copying from the right panel to the left). This would need the use of the higher codepoints, allocated much later (in Unicode 13, March 2020).
Currently the progress bar is painted using spaces, and accordingly, in the skin files, the background color of gauge matters and the foreground is ignored. I'm not sure from which other field the not-yet-completed part of the progress bar's color is taken from.
With the new approach, if enabled (i.e. in UTF-8 mode, plus maybe a config option), this color defined as the background of gauge would need to become the foreground color.
So, one way or another, we'd have to have some one-off exception. If we keep the current skin syntax then the background color of gauge actually moved to the foreground color of the corresponding color pair we allocate internally.
I suggest to use this opportunity to make the file's syntax more intuitive to humans, i.e. define a color where the foreground is for the completed and the background is for the yet-uncompleted part. Also, take this opportunity of a backwards incompatible change to rename the keyword to "progressbar": #3159.
Describe the solution you'd like
.
Describe alternatives you've considered
No response
Additional context
No response