feat: add signed & unsigned integer colour repr #27
Conversation
|
Naming seems good to me btw :) |
|
any updates on this? |
i forgot about it amongst a bunch of recent irl stuff. thanks for bring it back to my attention! i'll see if i can get it sorted today. |
todo: - [ ] naming - [ ] tests
772e9df to
4aac471
Compare
|
Feels weird adding this onto the color object itself (original palette data doesn't include this, can be generated via information on the color object already), I would think a filter would be better. 🤔 EDIT: Tested and works great for Aliucord. Still think it should be a filter though :D |
|
the whiskers models are not directly related to the palette json, so i'm not averse to adding new fields for whiskers. we also tend to use fields for, for lack of a better term, simple or obvious (edit: let's say intrinsic) formats of the colours (hex, rgb), and filters/functions for things that need to be chained or at least require more work to calculate. i readily admit that it's a pretty fuzzy boundary, though. that said, i did try a filter for this initially but i didn't find a design i liked that wasn't also cumbersome to use. i also considered just having a single int field that was tied to the hex format for component order/inclusion, but that felt too unintuitive. i settled on the idea of having these three fields that i feel to be the most common formats for now, then in future we could also add a filter for cases where you need more customisation and don't mind the extra overhead of having to use a filter for it. something like let me know how you'd like to see it as a filter, and the advantages it'd offer. |
|
Well I was thinking having a filter for each type of repr, so |
|
i see it more like the hex format - an exact identical/lossless representation of those RGB channels. |
|
Sure, whatever you are good with. Anything else left for this PR? Docs... fun. |
|
think so yeah, i'll update those when i get back and get this moving 👍 thanks for the input! |
todo: