This repository has been archived by the owner on Jul 12, 2024. It is now read-only.
Allow users to set their own accent color by passing in a color object #10
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
object (e.g. created with rgb()). This does not create any circular dependencies since it requires no knowledge of the rest of the template - just base typst type/function.
tinnet
force-pushed
the
allow-custom-accent-colors
branch
from
df95a57
to
e4295d5
Compare
|
Thanks @tinnet! Will update the submodule and the example repo very soon. |
mintyfrankie
approved these changes
Sep 21, 2023
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This enables users to use their own colors, e.g. from one of the many "resume color" guides on the internet (e.g. https://designshack.net/articles/graphics/resume-color-schemes/).
I decided to check the type of the passed in object instead of e.g. doing some magic string logic ala
awesomeColor.starts-with("#"), seemed more robust this way.This also still fails fast since either the user passed in a correct object, or it defaults back to the dictionary lookup that complains about any string that is not a present key -> the user can still be confused why passing in "neongreen" does not work, but no more than before this PR ;)
This does not create any circular dependencies since it requires no knowledge of the rest of the template - just base typst type/function.