-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Review: color consistency #108
Comments
Or give different colors different names? |
@lifepillar What do you mean? The issue, here, is that a given gui color can have different 256c and/or 16c translations across colorschemes. This is an inconsistency issue that should be dealt with. |
Isn't that two different colors ( |
No. One symbolic name, Don't worry if you don't get it, this issue is just a memo for later. |
Below are the tables of conflicting
|
In Colortemplate's documentation I wrote:
If you take blue as an example, |
The problem with this line of thinking is that the author of the original colorscheme deliberately chose a specific color with a fixed, standardized value. People use those colorschemes in the real world and I think that the pros and cons of changes like the ones you allude to must be weighted carefully. The originals are messy and we can't seriously claim that our remakes are an improvement if they are even more messy than the originals. Also, I think that we have more leeway in 16c land because of the inherent limitations of that color space. The constraints we deal with are much much difficult. In 256c, on the other hand, the technical limits/constraints are less stringent so we should strive to approximate the original as much as possible. Moreover, this project is a chance to replace an awful mess with a working "system", we shouldn't let it slip. |
Make sure that any given GUI color is always translated to the same 256c and 16c.
For example, LightMagenta, which doesn't exist in
rgb.txt
:The text was updated successfully, but these errors were encountered: