Thoughts on Colors #1107
Replies: 4 comments
-
Found this article today on blue, which I found interesting: https://bsago.me/posts/that-annoying-shade-of-blue This led me to the fact that Windows Terminal is updated it's default color scheme a while back: https://devblogs.microsoft.com/commandline/updating-the-windows-console-colors/
Related Issues:
|
Beta Was this translation helpful? Give feedback.
-
Regarding accessibility in colors: https://www.whocanuse.com/ |
Beta Was this translation helpful? Give feedback.
-
Great list of "falsehoods programmers believe about vision": https://news.ycombinator.com/item?id=32850662
|
Beta Was this translation helpful? Give feedback.
-
I would like to add my 5 gray rock coins. |
Beta Was this translation helpful? Give feedback.
-
Hello,
I was reminded today that our default color scheme works, but sometimes is too hard to spice up the UI in two fronts: customization of colors, and choosing different defaults.
This is not a proposal yet, just a place to share my thinking after years of delaying thinking about the problem.
On defaults, I think much progress could be made by having a text format to define the colors and allow for new themes to be loaded or changed this way. We could have a global setting as well as per-view ways of loading new attributes.
I suggest text because it would be simple for end users to customize this as well, something developers can use, without cooking their own.
So three components: parse color definitions, global settings and per view settings would be a starting point.
Before I talk about color parsing, let us address the other challenge: black and white vs basic color (extended color is not as big of a problem).
Colors are trivial, but our API does not make it easy to use- and this is to some extent done on purpose, because it could break black and white apps.
So the way to solve this is to use a sort of semantic sets of colors, we already have the basic 4 colors that can be used, and in reality, we use three basic sets for black and white (4 attributes for defaults, 4 for popups (dialogs), and 4 for errors - notice that dialog colors and menu colors are just two themes for the same concept: "not the main color scheme, and not an error")
Currently gui.cs uses attributes to encode those and out startup code assigns meaning to some core elements, either colors or black and white attributes so they work together. Black and white really imposing the limits here.
I think that what we need is to leverage the semantic meaning for those 4 attributes and 3 scenarios and expose those on the color file format.
By using semantic colors for that 4x3 setup, we could hardcode those values for b&w and let users define whatever they want for colors (basic or extended).
So the above could simplify themes, and different color identities. It does not solve making it easier to use new colors.
Here, I still think that there is value in defining colors semantically, to ensure apps run fine on black and white. And the api could be one to create a color given specific foreground/background attributes, as well as their intended effect (hot key, normal, disabled).
Will keep this here and digest a more specific proposal, just didn't want to forget this realization.
Beta Was this translation helpful? Give feedback.
All reactions