Color issues with the Solarized palette

[fbruetting]

In the solarized palette, most intensivated colors are diverted from their intended use and instead carry gray tones. It’s no wonder that this leads to issues. One case for example arises in the Julia language, as the Julia prompt uses green/yellew/red colors according to the respective mode. Of those colors, only the red one has a matching intensivated tone, which leads to gray and indistinguishable prompts / modes in the other two cases.

The hack version would be to just deactivate the “show bold text in intensivated colors” option, so that the regular colors get used, instead of the intensivated ones (which in fact are shades of gray).

Maybe a better solution would be to really split the Solarized Dark and Solarized Light palettes in two palettes, as the Dark variant just uses the two black and the two bright gray tones, whereas the Light variant just uses the two white and the two dark gray tones. Then the four colors green, yellow, blue and cyan could be duplicated, so that the palette can really work like it should.

By the way: Another thing I recognized, is that in the german translation, the color terms “Orange” / “Lila” / “Türkis” / “Grau” (english: orange/purple/turqoise/gray) are falsly translated and should be “Gelb” / “Magenta” / “Zyan” / “Weiß” (english: yellow / magenta / cyan / white) instead. [0]

[0] https://opensource-usability.blogspot.com/2018/11/why-linux-console-has-sixteen-colors.html

[phw]

Regarding translations you can help updating them at https://hosted.weblate.org/projects/tilix/translations/

Although I don't think we should translate orange with gelb and purple with magenta etc. If the colors really should be named differently I think the English source text should be updated first.

[egmontkob]

just deactivate the “show bold text in intensivated colors” option

Yes, the proper use of Solarized requires this to be turned off.

Maybe a better solution [...] so that the palette can really work like it should.

The exact colors for the 16 slots are defined on the Solarized homepage, section "The Values", the "Hex" and "16" columns from the table. If you come up with anything different, it's no longer Solarized.

By its very nature, colors of the Solarized palette don't match the standard names of these color slots. (BTW you're right about Tilix using some nonstandard names – also on the English UI, it's not a translation issue as phw correctly pointed out.)

Tilix seems to correctly define the Solarized palette (except that each color channel has a one lower value than desired, probably some rounding error from float conversion or so).

[fbruetting]

As the Solarized webpage points out, that just 5 of those 8 black/gray/white colors ever get used in one of those Dark/Light modes. I think it would be good if at least the other three “false” colors get replaced by a copy of the respective highlighting color. Then we would have just one total color mismatch instead of currently four.

[egmontkob]

just one total color mismatch

Or you could still fully respect the definition as per the table I mentioned, rather than coming up with individual nasty hacks, and disable "Show bold text in bright colors". This results in zero color mismatches. Isn't this a better approach in all aspects?

But let's add one more thing. The Solarized definition isn't aware of the concept of "default background color" and "default foreground color" that terminal emulators have. Terminal emulators have figured out the desired value for them from the screenshots that you posted. That being said, you might configure some of your applications in a way that they never rely on the terminal emulator's default colors, that is, they decide themselves whether to use the light or dark variant. You might even place a light and a dark one next to each other in tmux. Your proposed modification to the palette would break it if an app picks the other variant than the terminal emulator's.

[fbruetting]

I really don’t understand your first paragraph. And we need a hack to make it less broken – and it IS broken. Still it remains Solarized, as the colors are the same, just the implementation gets some fix.

The official Solarized color palette is both the Dark and the Light variant in one, this is nowhere needed and the superfluous colors can be used to fix the total color mismatch issues. And the applications exactly should rely on the terminal emulators color instead of deciding themselves what variant to use. Why should an application use Light when I set Tilix up to use Dark? That’s nonesense. If they do make decisions on their own, they should have their own palette instead of relying on inverting the one of the terminal emulator.

I therefore created the merge request #1580, where I deleted the specific superfluous colors, moved the foreground/background colors into their according correct slots (instead of having them using color slots) and I duplicated the now freed color slots for avoiding the total color mismatches.

There is absolutely no reason why the Dark and Light variants need to be in the same palette, so this fixes the mentioned issue by splitting them into proper palettes of their own.

The exact color codes still are somewhat off. I don’t know why, but if there’s no real reason, this could be fixed in addition.

[egmontkob]

I'm not Tilix's author to make any decision here, but I'd like to firmly point out again that you're changing the color scheme against its definition so that it can no longer be called Solarized.

And the applications exactly should rely on the terminal emulators color instead of deciding themselves what variant to use.

Says who, where?

Why should an application use Light when I set Tilix up to use Dark? That’s nonesense.

Neither of us are the designer of Solarized. The designer of Solarized specified for each of the 16 palette indices the exact corresponding color. Even if you shuffle the indices, it's no longer Solarized – it potentially breaks the look of applications that expect the real Solarized.

Note that I'm not trying to defend the design. I don't know if it's a good or a bad one. I don't know if your design would be a better one. Could be. I'm defending Tilix's implementation of the Solarized 1.0.0beta2 specification (except for the off-by-one, now I see in your patch that simply the hardwired hex values are off).

If you have a problem with the design, I believe you should discuss it with Solarized's author rather than with those who implement it. The current version is 1.0.0beta2, maybe he'll adjust to specification according to your feedback for the final 1.0.0, and then it'll be a fair request for Tilix (and tons of other terminal emulators) to adjust.

[gnunn1]

The issue with the colors being off by one is on me, I simply cribbed the palette from gnome-terminal and translated the colors. The problem is gnome-terminal originally had them as decimal colors rather then hex and being new to the game (i.e. just starting development of Tilix) I obviously made a math error or something.

My point of view is that the solarized palette and colors in Tilix should match gnome-terminal because that is where the average user of Tilix is coming from and what they are expecting to see. Since color themes are externalized in files in Tilix if people want a modified or improved version of it they can simply create their own as needed.

Thus the fix for this issue is simply correcting the palette off by one colors IMHO.

[egmontkob]

gnome-terminal originally had them as decimal

I think we had them as floats (doubles), which was a pretty bad idea. And I honesly didn't understand why they weren't rounded downwards on our canvas :-)

[fbruetting]

The hack version would be to just deactivate the “show bold text in intensivated colors” option, so that the regular colors get used, instead of the intensivated ones (which in fact are shades of gray).

What about that at least? Don’t know if this can be done per style, or if this is a global setting.