-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Add Color::parse
#2486
Add Color::parse
#2486
Conversation
b8e57a6
to
b49f0b5
Compare
You missed the format |
Is there a reason you don't use the more self-explaining |
b49f0b5
to
89c32dc
Compare
@VAWVAW Good points, thank you! Fixed. |
1f30695
to
ef179c7
Compare
@n1ght-hunter Oops, I didn't know about That being said, I still think my PR has certain advantages:
If this PR gets merged, I'll send another patch to have |
i would love this. Sort of annoying when I open a hex color editor, pick a color and I can't easily use it to color buttons and whatnot. |
@hecrj Let me know if you want any changes on this (or just don’t want it which is fine). |
084aa40
to
523708b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
I renamed the method to parse
, which I believe conveys clearly that there is a runtime cost involved with this helper.
The color!
macro should be preferred since it leverages hexadecimal literal notation and arithmetic directly. The compiler is able to optimize most of these operations away in most cases, so no parsing and runtime cost necessary.
I have also extended the macro to support short hand notation and added some debug assertions for good measure.
This function has certain advantages over creating hex colours with
color!
:#ffffff00
#fff
notationcolor!(0xfafafa9)
and there won't be an error, despite the hex string being invalidIf this PR gets merged, I'll send another patch to have
color!
usefrom_hex
.