Support white background terminals

[ivanzoid]

Please make support for terminals with with white background ;)

[schachmat]

Currently wego uses many of the 256 ANSI colors to „encode“ the temperature and windspeed values as well as a few shades of grey (pun intended) for different cloud coverages. A b/w only switch is already planned. It may be useful to provide another mode which only uses the first 16 colors of ANSI, which are mostly guaranteed to work with every (sane) colorscheme. These color may be arbitrary though so the colorcoding would be restricted in red, yellow/brown and green.

Does anyone have any further ideas?

I am using the solarized colorscheme, which works very well (see the screenshot in the README).

[lolstarz]

I think a b/w switch would satisfy the majority of users. Another option might be to take the background colour as an argument, then use the ANSI color table to determine a minimum delta for conflicts -- if a colour used in wego is within the delta (too close to the background colour provided), select another colour outside the delta.

Might be over-engineering for the problem.

[lucaswerkmeister]

You should also avoid using hardcoded escape sequences for coloring, since not every terminal uses xterm-compatible escapes (real-world example: fbterm). In shell scripts, I usually use tput for that (tput setaf 1); perhaps there’s also some Go library to directly use terminfo.

[pallavagarwal07]

If nobody is working on this, I have something that might be useful.

[schachmat]

What's your plan @pallavagarwal07?

[pallavagarwal07]

Since all color codes are hard-coded, it would be difficult to change all of them, not to mention that dark colors for sun and such won't look so perfect. I was thinking that the switch could merely change the background of the printed lines (i have already done sample changes to the code, and will post the screenshot in a minute)

[pallavagarwal07]

https://drive.google.com/file/d/0B6jsnt965ZwrQWUtUVpQZ2pGQ1U/view?usp=sharing

[pallavagarwal07]

The top para hasn't been fixed yet, but the rest looks good

[schachmat]

I don't like inverting the brightness of the user-defined background. I have a dark background and to not get Eye-cancer all the time, I installed a custom dark css in my browser too. However defining some kind of customizable colorscheme could work.

[pallavagarwal07]

In the current code, that would effectively be rewriting the whole source. Everything is hard coded - especially the slicing of strings is causing trouble
eg. \033[38;5;53m has different number of characters than \033[38;5;153m
I see what you are saying, but I mean it as an alternative IF user wants. Currently, the script isn't very usable on light backgrounds.

[schachmat]

Sorry, but it's not the proper fix. I know that everything is hardcoded atm and that it's a mess and I am sure, it will be some pito to fix it up, but it is necessary and inevitable for the project to move forwards. #1 is a strong first step in cleaning up and I hesitate to fix #7 or merge #16, since I think it will make #1 harder and after #1 is done, they should be easier to fix.

[pallavagarwal07]

Ok. Anyway is there anything I can do to help (for any issues, not just the current)?

[schachmat]

As I said, #1 is the next big thing. If you want, you can give it a try. I will post some thoughts and plans for it in the respective issue now.

[pallavagarwal07]

Ok

[mtelesha]

How about supporting Solarized colors. The colors are readable with light and dark backgrounds? The only change between light and dark Solarized is the color of the background and does not change any other color.

[schachmat]

As you can see in the screenshots, I am actually using the dark solarized color scheme. However for the colors in wego I mostly use the ones from the colorcube, which is not (and should not be) changed by dark/light versions of solarized or any other color scheme at all. They are hard defined, which exact color they represent and that is, what I rely on. Having purple clouds or a green sun if I use another colorscheme would be strange at least. Therefore I cannot use the first 16 colors, which should be the only ones affected by color scheme selection.

[Hultner]

Is this still being worked on?

[schachmat]

Well it's not high priority for me, but if anyone would come up with an elegant b/w solution (basically removing all the color codes), I'd be happy to merge it.

[schachmat]

Thanks to @mattn adding it to go-colorable this is now supported with the new flag -aat-monochrome. Run go get -u github.com/schachmat/wego to update.

[Hultner]

While this makes it usable in a light terminal I think that most would prefer a coloured theme more suitable for the "light background & dark foreground"-type terminal themes as an option. Or should that be tracked in a new issue?

[schachmat]

I don't think this could be made to look nice. The runes used are mostly filigree and there would be very low contrast between the bright background and the colors yellow (sun) and light gray (clouds). I've tried it myself and you can also see the problem in the first screenshot of this thread. The terminal isn't fit to draw arbitrary filled shapes (also it wouldn't be "ascii art" anymore) which imho is needed for this low contrast use case to work.

[lexicalunit]

@pallavagarwal07 I had the same idea as you but I simply wrapped wego in a script to force a dark background. I added blank lines before and after, as well as a few spaces to the start of each line, to provide some dark background padding for the content. I think it looks really nice.

#!/bin/bash

esc=$'\e'
bg="$esc[48;5;232m"
eol="$esc[K"

echo -e "$bg$eol"
wego "$@" | sed "s/^/$bg$eol  /;s/\[0m/\[0m$bg/g"
echo -e "$bg$eol"

As @lucaswerkmeister mentioned there is probably a more portable way to write this using tput but this works well enough for my purposes.