Adding custom coloring support

[tarasivashchuk]

Hey, so I saw that you have adding coloring options in the to do, so I thought I'd open an issue for it for discussion as I wouldn't mind working on it. I was going to utilize colorama, but am open to suggestions as well as I haven't really used that library before so either way it will be something I'm learning.

Where are you at with this as of now? Thanks!

[rsalmei]

Hey @tarasivashchuk, thank you, it would be awesome!

But do you realize how much trouble is that? It's actually way harder than it seems. The problem is not generating the colors on the terminal, which is what colorama does... I did that manually in my other project clearly here, it's simple.
The problem lies on having to have string-like objects that support: len, indexing, slicing, concatenation and reverse without losing color information!! 😨

Imagine this, a colorized text in a terminal have the format "Color Escape Code text Reset Escape Code" or two colors in sequence, for example:

• "ESC[colorcode1m txt ESC[0m", or
• "ESC[colorcode1m txt ESC[colorcode2m abc ESC[0m"

So for text = '\033[91mnice\033[92mone\033[0m' like this:

these operations would have to work:

• len(text) == 7 <-- that colored text has 7 chars, not 21
• text[2] == '\033[91mc\033[0m' <-- at index 2 we have a red 'c', not '9'
• text[3:5] == '\033[91me\033[92mo\033[0m' <-- a red 'e' followed by a green 'o', not '1m'
• text + '\033[94mhuh\033[0m' == '\033[91mnice\033[92mone\033[94mhuh\033[0m' <-- this is simple, the reset is removed
• reverse(text) == '\033[92meno\033[91mecin\033[0m' <-- this is the hardest one

It's that tricky....

Regarding the state I'm with this, I like alive-progress to have no dependencies at all - it's even in the README - so I started my own implementation, and actually made it work for the first two cases of len and indexing! But couldn't in a reasonable time make the others work... 😓

That's when I went to see if there was something ready, and found the cool colorful project! The author timofurrer was very helpful and also made it work for these same cases as I did, but not the others yet. I recommend you read the issue I have there to have more context: timofurrer/colorful#35

Maybe you could help him there! Which would also help here a lot! If that work, integrating it here should be relatively easy...

Thank you man! Appreciate your help 👍

[rsalmei]

What I like the most in colorful is that it also does not have any dependencies, like here. So, I could put an optional dependency for color support, and if someone needs it, only one other package would be fetched!

Then the install could support something like:

$ pip install alive-progress[color]

How cool would that be?
Of course it complicates implementation, since a package may not be found and all would have to work the same...
Ohhh, and when we have spinners with color information AND the color support enabled, how would a user request the usual monochromatic spinner?

Well, what do you think of all this information?
Thank you again! 😅

[jazz-it]

Sorry for raising the old topic again, but I need to ask if there's a chance for this approach in order to colorize the entire output from alive_bar with the same color:

config_handler.set_global(fg_color="ESC[colorcode1m")

EDIT: I just realized the above suggestion is achievable with:

COLOR = "ESC[colorcode1m"
with spinner(COLOR + "SOMETITLE"):

[ThomasByr]

Hi! Sorry to write in an old topic.

It seems that the colorful library does not receive updates anymore.

An easy (temporary) solution could be to add a color argument to the bar_factory for both the chars and the background.
Color would be applied after slicing, basically wright before printing.

edit:
this is basically to acchieve something like the "pip install" progress bar (where only the colour indicates the progress)
afaik, monitor, elapsed and stat (in config_handler) do not need such additional care since they are not sliced

when this comes out, i'll be more than happy to create a custom new theme called "pip"^^

edit n°2:
so far, just adding a keywork to treat a sequence as only one char may work
if the user guaranties that this sequence represents a char surrounded by color code

[rsalmei]

Hi @ThomasByr! No need to apologize at all, it is still open after all.

You are absolutely correct!! I don't know why I always thought about color support in the spinners... I guess it was for consistency, to either support it in full or not.
But it's in spinners that it is extremely hard because of the slicing to create animations, and only in there! Anywhere else it should be simple enough!

Well, the word "theme" is already taken, but I do like the idea of having some "color config" that applies colors to individual widgets, right before printing... That should be way simpler than applying to parts of a spinner like before.
And, since themes aggregate "styles", bar, spinner, and unknown today, I could surely extend it to include colors too!

Thanks, man. Very nice ideas here.
Perhaps that could be a nice 4.0 major version.

[rsalmei]

Wow, it's much more complicated than I initially thought... It changed the size of the cells, which made the Cell Architecture remove the colors in some cases, but I've worked around it.
It's still very raw, but here is the first color testing:

Screen.Recording.2023-10-23.at.22.01.47.mov

Success!!! 🎉

[ThomasByr]

wow very nice ^^ the result looks awesome ! hyped for this

[rsalmei]

Thanks, man!
Now I have to create some kind of configuration system for it, and a concept of a "color theme" to allow aggregating multiple of these configs at once... I'll work on them in the next weeks 😜