- User Since
- Mar 11 2019, 8:27 PM (18 w, 2 d)
May 8 2019
In this case, I tried to clamp the values before generating the HEX value, but the color still changes. The problem is that HEX is not able to represent HDR, so when the colorspace conversion function is applied, some weird color is generated instead. Since this is a limitation of the hexadecimal representation, there is no fix for this issue. So, we decided to prevent the user from editing the HEX input field if the RGB value cannot be represented as HEX. The only problem is that when the user actually wants to input a HEX value in place of a non-representable value, the RGB values will have to be corrected before the HEX field becomes editable.
Apr 24 2019
Apr 23 2019
Apr 22 2019
Are the color picker number sliders supposed to accept values greater than 1? Because it currently accepts them:
Apr 17 2019
Updated the function comment.
Apr 3 2019
Hi, just as a reminder of this DIff I am bumping this thread. Sorry if this is not allowed, but it has been a while since my last diff update.
Mar 27 2019
That flag free_src was there in case of reuse of the function, but I think there will not be many reuses, so removing it may be better.
Mar 25 2019
Changed what was suggested.
Mar 20 2019
I have implemented the suggestions in code style and structure.
As converting from tabs could lead to unexpected behavior, I kept the text unmodified in this case.
Mar 18 2019
off topic: Should I post the code as I mark the comments as done, or should I wait until every comment is solved to post?
Mar 14 2019
Mar 13 2019
I, with a friend @Victor Seiji Hariki (seijihariki), have developed a fix for this issue. This is our first contribution and we would like to know how to submit it for review! It seems it was a problem of converting tabs and spaces when pasting text.