search

catppuccin / whiskers

😾 Soothing port creation tool for the high-spirited!
MIT License
15 stars 2 forks source link

feat: add signed & unsigned integer colour repr #27

Closed backwardspy closed 1 week ago

backwardspy commented 2 months ago

todo:

uncenter commented 2 months ago

Naming seems good to me btw :)

NeonGamerBot-QK commented 2 weeks ago

any updates on this?

backwardspy commented 1 week ago

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.

uncenter commented 1 week ago

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

backwardspy commented 1 week ago

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 {{red | intrep(bits=32, order="rgba")}} for example.

let me know how you'd like to see it as a filter, and the advantages it'd offer.

uncenter commented 1 week ago

Well I was thinking having a filter for each type of repr, so {{ red | sint32 }} instead of {{ red.sint32 }}, and so on. I thought this was the design of the API when first testing it out in Aliucord but I had to take a look at this PR's code to understand. This feels similar to the css_rgb-type functions, where you can format the existing RGB data into the CSS format. In this case, you can format the same existing RGB data into this different format.

backwardspy commented 1 week ago

i see it more like the hex format - an exact identical/lossless representation of those RGB channels.

uncenter commented 1 week ago

Sure, whatever you are good with. Anything else left for this PR? Docs... fun.

backwardspy commented 1 week ago

think so yeah, i'll update those when i get back and get this moving :+1: thanks for the input!