I want to keep the primary documentation digestible, but there are a lot of common use-cases that are a little tricky to figure out. I'm going to start adding those to the examples directory
I want to keep the primary documentation digestible, but there are a lot of common use-cases that are a little tricky to figure out. I'm going to start adding those to the examples directory
now you can modify the colors used to render different parts of the keycaps! This will be used in some examples to draw ghostly outlines of components.
Also make the keytop width changes less dramatic, by centering them around the center of the sides of the keycap. Now instead of choosing the front or back of the keycap and shrinking / expanding the back or front to fit, we shrink / expand both evenly. This actually cleans up the logic too! hooray.
This has been and will remain a passion project of mine. I've always struggled with donation links for, I hope, the same complicated reasons most people would: is bringing money into a hobby worth it, that hobby's "worthiness" to carry a donation link, whether the link gives off a sense of entitlement, etc etc. All that aside, I've really come to appreciate the support from the community - I love encountering uses of KeyV2 in the wild, any PR requests submitted, and some people have said such nice things. Donations for open source projects has a storied history, in my opinion all the more normalized by the recent trend of Twitch subscriptions / patreon / etc. Far be it from me to let my awkwardness stop someone from supporting this project in that way - besides, we're at a point where that money could easily be put back into the project via purchases of keys or switches to implement, or bounties.
So yeah, those are my thoughts on this. Donations are very welcome and super appreciated, and completely voluntary and optional.
I _highly_ recommend running the code properly in OpenSCAD, though I'm going to put roadmap enhancements for making this library more accessible to people who don't want to do that.
make square_shape and rounded_square_shape use trapezoids as their top surface, perfectly shaped so that the sides of the keycap are flat, and can be used as a printing surface
not sure where but `depth_difference` for `shape()` is being left out. defaulting to 0 (which should be fine for a delta variable anyways) fixes the issue
I'm at a bit of a crossroads as without the elephant's foot brought about by printing the keycaps right side up, with no stem inset, I can print these stems with no inner slop and they fit _fantastic_. But we've had slop in the stem for printing right-side-up since inception, so switching now is probably not a good idea. this warning might be good enough
