You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
My problem is that I'm trying to do dynamic/custom theming and so they way I have it setup is I use templates for each of my dotfiles to get a color from their variables like {{ background_color }}. For dynamic theming I just want to put the theme file in includes that will have the background_color def and all is well. However I dont want to hardcode colors like that as they get repeated throughout all the theming of multiple packages but 1 package may have a different background_color to another for reasons, and so I want to be able to define a list of my colors and then assign those colors to specific color variables used by packages.
Currently the way I do this is through handlebars lookup with lookup colors background_color. However I didn't like this solution much and it causes an issue with per-theme possible multi-level linking such as if I had a base color palette, and then I wanted to define primary and text in terms of the palette and then something like background_color could potentially use primary which would link to a palette color like red, and so for now I am just redefining the hex color for primary
Describe the solution you'd like
A nice solution would be able to use variables within the TOML files so I could keep color choosing logic on the dotfile manger and the actual dotfile template just needs to know to expect a variable that is the hex color it wants so:
the template can do {{ background_color }}, then in the .toml I could do background_color = {{ primary }}, and primary = {{ red }} and then finally red = #ff0000.
Describe alternatives you've considered
The other solution was the one I mentioned above I guess with doing it in handlebars but its limited. I can't think of any other nice ways to handle this, it is an odd problem in the first place to be fair
Additional context
Maybe this is out of scope of TOML files, I've seen that the creators of TOML want to keep variables outside of it in general and so thats fair, and like templating on the TOML wouldnt work because those variables are already in there? I guess it could be very awkward and so very fair if this request is just not well thought out and misses a lot of cases. Open to any other ways I could handle this task
If my explanation was confusing I'm very sorry, please do ask any questions you have and you can check my dotfiles repo I have what I'm talking about setup there with my theming for stuff like wofi, swaylock, alacritty
The text was updated successfully, but these errors were encountered:
In my opinion this feature would be outside of dotter's scope. On the other hand you could use a build step that compiles a dotter spec TOML for you from any language (say JavaScript or Python), would that solve your use case?
Is your feature request related to a problem? Please describe.
My problem is that I'm trying to do dynamic/custom theming and so they way I have it setup is I use templates for each of my dotfiles to get a color from their variables like
{{ background_color }}
. For dynamic theming I just want to put the theme file inincludes
that will have thebackground_color
def and all is well. However I dont want to hardcode colors like that as they get repeated throughout all the theming of multiple packages but 1 package may have a different background_color to another for reasons, and so I want to be able to define a list of my colors and then assign those colors to specific color variables used by packages.Currently the way I do this is through handlebars
lookup
withlookup colors background_color
. However I didn't like this solution much and it causes an issue with per-theme possible multi-level linking such as if I had a base color palette, and then I wanted to defineprimary
andtext
in terms of the palette and then something likebackground_color
could potentially useprimary
which would link to a palette color likered
, and so for now I am just redefining the hex color forprimary
Describe the solution you'd like
A nice solution would be able to use variables within the TOML files so I could keep color choosing logic on the dotfile manger and the actual dotfile template just needs to know to expect a variable that is the hex color it wants so:
the template can do
{{ background_color }}
, then in the.toml
I could dobackground_color = {{ primary }}
, andprimary = {{ red }}
and then finallyred = #ff0000
.Describe alternatives you've considered
The other solution was the one I mentioned above I guess with doing it in handlebars but its limited. I can't think of any other nice ways to handle this, it is an odd problem in the first place to be fair
Additional context
Maybe this is out of scope of TOML files, I've seen that the creators of TOML want to keep variables outside of it in general and so thats fair, and like templating on the TOML wouldnt work because those variables are already in there? I guess it could be very awkward and so very fair if this request is just not well thought out and misses a lot of cases. Open to any other ways I could handle this task
If my explanation was confusing I'm very sorry, please do ask any questions you have and you can check my dotfiles repo I have what I'm talking about setup there with my theming for stuff like wofi, swaylock, alacritty
The text was updated successfully, but these errors were encountered: