Closed ahmedmahmud closed 1 year ago
Thought I would add this in as well: My use case is that I am trying to define variables for specific colors that my configs use, and then in the configs I can choose what color is assigned to what throughout my configs in one place so like:
variables:
colors:
primary: "#b4befe" # lavender
rosewater: "#f5e0dc"
# swaylock:
bs_hl_color: "{{@@ colors.primary @@}}"
# wofi:
background_color: "{{@@ colors.rosewater @@}}"
However if some variablea have shared names like text_color
or background_color
in the configs its a clash, even if they may have different colors assigned to either. So for now I just prefix the variables with like wofi_...
but it would be nice to put these in a tree structure instead
Hello,
I was surprised to see that wow: "{{@@ hello.k @@}}"
even worked ;-) Currently dotdrop handles variables as a flat dictionary with no support for nested variables. The reason why wow: "{{@@ hello.k @@}}"
works is that the templater (jinja2) does handle nested variables and hello.k
was defined. However it wasn't able to template the value of the
z
variable since it is a dictionary ({wow: "{{@@ hello @@}}"}
as opposed to a string).
I'm going to look into this and try to add support for nested variables. I'll keep you posted.
Regarding your second question, can you elaborate on what you mean with have shared names
with an example?
@ahmedmahmud I made an attempt at handling nested variables (dictionary-like) in the nested-variables branch. Can you give it a try to see if it matches your expectations?
Here you find a test I wrote for checking that feature. It's minimal so if you have more use-cases I could test, feel free to do a PR or just provide them here. Thanks!
Thanks for getting back on this so quick. I gave it a try and it works perfectly for my case! My use case isnt really any more complicated than your test though so I wouldn't be able to catch any edge cases there. About the shared names I mean something like if I couldnt nest them and both rofi
and waybar
for instance need a background_color
I'd be forced to do:
rofi_background_color: ...
waybar_background_color: ...
but now I can do
rofi:
background_color:
waybar:
background_color:
which is very nice, thanks!
Nice :+1:
This was merged in master and will be part of the next release. Thanks for you help on this.
@ahmedmahmud this new feature has been released with version 1.13.0
, thanks for your help on this!
Hi so when defining variables something like this is allowed:
However when doing
dotdrop errors with:
Is this a limitation on purpose? Or maybe there is a different/better way to approach/do this? If not this would be nice. Thanks