Hashmap for Colors

[rzerres]

Context:

Introduce a central const_colors to hold color name constants.

Reference to a related issue in the repository. @FloVanGH

Contribution checklist:

• [x] Add documentation to all public structs, traits and functions.
• [x] Add unit tests if possible
• [ ] Describe the major change(s) in the CHANGELOG.MD
• [ ] Run cargo fmt to make the formatting consistent across the codebase
• [ ] Run cargo clippy to check with the linter

TODO

• [x] Review and discuss the proper mechanism to implement lookup for colors
• [ ] Convert all hex values to proper fn rgba calls
• [ ] Update all examples to use the new global constants
• [ ] Update themes to use new global constants

[sandmor]

That color list is... horrible in various dimensions, it has entries like "demonic presence", "blue angel", "witches cauldron", "bats blood soup", "wicked green", "diablo red", "zeus", "macabre", "vampiric shadow", "celestial dragon", "buddha gold", "merlins cloak", "santas grey", "apollo bay", "satan", "blood god", "baal red wash", "batman", "accursed black", "seraphim sephia", to give some examples I don't want to work in a project with this things... some of the mentioned above does not have bad connotations but I prefer maintain supernatural, religious and in general fiction things away. Also, for just performance, its log2 is 14.6, while the log2 of the list would be around 7, this doubles the number of decisions to take in a binary search, also is inefficient for the processor cache, slowing it even more.

[sandmor]

What do you think @FloVanGH?

[FloVanGH]

I think the intention behind this naming is to use the default css color naming. Personally I have not problem with these names but I'm also open for good alternatives.

[kivimango]

I think using "official" names for colors would be more professional and UI/UX designers would be more familiar with them ( and more consistent since we are already using them in the default themes (like Gold Tips, Alabaster, etc).

[rzerres]

• Color names I don't have any limiting requirements. I was talking to @sandmor the other day about "good names", "official names", etc. He pointed out the link with a faily complete list of names. I don't know, if there is common sense within the developer community (Linux, MacOS, Apple, BSD, etc.). I don't like supporting idioms, that knowbody realy will use. I view this cases as individuel gusto. We should maintain names, that have a global acceptance. But i have no clue, which one are fullfilling this requirements.

• Who is selecting Beside the fact, that we have to select the 'right' names, its a timeconsuming task. There are simply so much to select from. Who is going to do that?

• Speed and size Having static variables for the glyphs will help to reference them, get them into the documentation .... Since glyphs can be assigned inside the theme an source, they get compiled in via your cargo calls. In terms of speed, it shouldn't make a difference if the amount of static color variables is big or not. If we put them into a hashmap/phf we could enable the developer (some day) to search inside the map within the desing phase. For me, convinience will beat speed. This is a perspective for an iteractive editor or helper tool. maybe we can go with a cheetsheet as done for icon/asset fonts.

Inside the application we should omit to use dynamic lookup calls (@sandmor: your log2 argument is obvious).

[arctic-alpaca]

Using css colors could be a starting point. Those are sufficiently well defined and since they should be supported by every browser, they should be as close to global acceptance as one can get.

[sandmor]

Currently, we used the CSS colors and some others, is possible to limit it to the only CSS but... the default themes use someones that are not there. Also, I don't see the benefit in the use of problematic ones except discourage some developers of contributing to this wonderful project. We need more developers not less

[sandmor]

your log2 argument is obvious

But I wanted to do a point :slightly_smiling_face:

[sandmor]

Also, that list comes from here, a GitHub repository that aims to create the largest list of colors possible, they are not official names but color names picked by someone that fills its formulary or simply do a tweet on Twitter, worth the redundancy. I think it would be unprofessional to include a list made by random people around the world with the sole objective of making "the longest possible color list".

[arctic-alpaca]

Currently, we used the CSS colors and some others, is possible to limit it to the only CSS but... the default themes use someones that are not there.

How about prefixing them with something like "orbtk_"? This would make it clear, that it's a custom color used in OrbTk and distinguished from well known colors like css ones.

On the issue on which colors to include. I think a good intial point is including css and every color needed for the default themes. Anything else could be added by people in their own project.

[sandmor]

He pointed out the link with a faily complete list of names

I said that I have many entries not that all of them were publicly accepted and say that to @rzerres to try to help him to process the current OrbTk publicly accepted color list that although not complete all of its colors are official ones and not picked by a random guy in someplace.

[sandmor]

On the issue on which colors to include. I think a good intial point is including css and every color needed for the default themes

Well, when current list was made that was the idea but after I attempt to modify the themes and start to add colors to it after I don't see the benefit on removing them because I take it from reliable sources, so the list stayed like this, since then no color has been added or deleted

[sandmor]

Also, @rzerres I don't want to harass you, I only don't think this list would be here and I do not like its entries that are not standard, sorry if I made you think that by mistake when I mentioned it.

[sandmor]

How about prefixing them with something like "orbtk_"? This would make it clear, that it's a custom color used in OrbTk and distinguished from well known colors like css ones.

That looks like a patchy solution to me if I can say it, because they would be exposed to the public, I prefer to maintain the current color list but I don't want to impose my opinion, for me the color list does not require additions or removals currently

[lukors]

I'm not 100% sure what's going on here, some comments seem to be missing, but I'm going to throw my opinion in the mix in the hopes that I have interpreted the situation correctly:

A standard list of colors should be used. The one linked above seems good to me since OrbTk project makes use of CSS: https://www.w3.org/TR/css-color-3/#svg-color

No names for colors used in official themes should be added. Why should they? This list of color names is just a convenience, and adding any extra just moves away from a standard. if you want some specific color you can type in the rgb manually, or maybe CSS has some way of naming colors within a CSS file?

If some non-standard color names are used in a theme, just update the theme accordingly and there's no issue.

[hardBSDk]

Redox moved to GitLab years ago, thus if you still want to merge it, move this pull request to there.

If you still want to contribute to Redox, talk with us in the Matrix chat.