Closed MoburgLeGrand closed 3 years ago
Hey, thanks for the feedback.
At the current time, it is indeed intended behaviour.
update
can redownload:
lists
: Schemes and templates lists from these repositories, changable by editing ~/.local/share/flavours/base16/source.yaml
. These lists then get saved (and replace existing files) on ~/.local/share/flavours/base16/sources
.schemes
repositories, as specified by the file ~/.local/share/flavours/base16/sources/schemes/list.yaml
. For each scheme name, it removes the old directory and replaces with the newly cloned one. So, this shouldn't remove custom schemes that don't collide with upstream names, but does replace your scheme if it exists upsteam.templates
repositories, as specified by the file ~/.local/share/flavours/base16/sources/templates/list.yaml
, with the same behaviour as above, but for templates.With the option all
doing all of the above.
I designed it thinking about a program that requires little to none prompting when updating schemes/templates, with the "correct" way of adding custom schemes/templates being, after writing locally, pushing them to a git repo for safety and adding that repo to the respective list.yaml
file (optionally also contributing that addition to the official base16 lists). As schemes are each their own thing (so, the more the merrier), and templates for a specific app should be universal and work for any and all use cases, in a very generalized way (even if they don't, then the user should probably add a subtemplate that makes it work and contribute that to the existing template upstream).
I do see that now (actually have been brainstorming about this recently) this might be unwated behaviour, as upstream seems to be reaaaally slow maintaining lists (so most users end up either making non-tracked tweaks/additions to their lists), and sometimes have custom edits that simply don't make a lot of sense pushing to a git repo.
I'll futurely (probably) make a more featureful update command. Including diffing the lists/schemes/templates when pulling from upstream, pulling instead of cloning, and support updating subtemplates while keeping custom ones intact. I just need to take a look on how existing tools (such as plugin managers) work with git to minimze user interaction and verbosity (although verbosity and interaction might be preferrable in the update
command, as it isn't used very often).
All in all, i ended up designing with "quietness" in mind, and this works with my original intended workflow (good enough schemes should be contributed upstream right away, templates should be as general as possible and require no tweaking whatsoever, and even if they do, that tweaked version should be a subtemplate and be contributed to upstream too), but is not very good if you prefer to keep non-tracked local changes.
Sorry for the lengthy reply, so. as for your use case, i would either:
xresources-tweaked
), and preferrably make a git repository for safety (if you do, add it to ~/.local/share/flavours/base16/sources/templates/list.yaml
.list.yaml
file i mentionedFor all of the above that involve editing any list.yaml
, remember to avoid running flavours update lists
and flavours update all
, as that will replace your lists with upstream lists (i personally have a lot of templates and schemes that i created, but base16 maintainers are reaaally slow merging PRs, so i never update my lists with flavours, i manually add entries as they are added upstream)
I also would've like to add that you can use rewrite=true
on your ~/.config/flavours/config.toml
, for the cases where the template should replace the entire files (which i believe is what you might need?).
Let me know if that works for you, and feel free to drop how your .Xresources should look like and i'll be glad to help you out :)
Thank you for this awesome answer. Indeed, everything you said make a lot of sense, and the intended behaviour seems pretty fine to me now. I think I was mainly confused because I must be a lot less experienced than your average user. Which I think is OK and could help making your awesome tool even more user-friendly if that's what you aim for (and I think it is, since it's already pretty darn usable for someone like me). What you could do to help people like me understand it a bit better and not make mistakes while still retaining all the intended behaviours :
As for my case, I realized I could do way simpler. My problem was that I have urxvt settings in my .Xresources that I wanted to keep, and since I couldn't use the # flavours tags
I had to use rewrite=true
, so I just decided to put my urxvt setting directly into the template.
The obvious solution was to write all the color info in a subfile that I source in my real Xresources, and rewrite only the colors file with flavours. This works perfectly well and seems a simple and elegant enough solution. I just didn't think about it before because I still have a lot to learn in managing files and configs efficiently, as I'm pretty new to the linux world.
Anyways, thanks for the awesome development and answer. I noticed you wanted help for the doc, so when I feel more comfortable with your tool I'll be sure to tell you if I see anything I think should be added / said more clearly.
Thanks a lot for all your feedback and kind words!
I like these suggestions, and will surely implement a warning and write better docs about update
.
I'm glad you got urxvt working. You're 100% right, sourcing a separate file (when supported) is definitely the "way to go". Just as tip for future configurations with non-default comments and no support for sourcing separate files, you can actually change the start
and end
comments! Here's an example with css files (which has /* foo */
comments):
[[item]]
file = '~/.config/beautifuldiscord/style.css'
template = 'styles'
subtemplate = 'css-variables'
start= '/* Start flavours */'
end = '/* End flavours */'
I think this is mentioned somewhere on the README.md, but it's definitely a documentation problem this not being more accessible for people starting out, and i will for sure tackle this problem (i was thinking on documenting the configuration options on a flavours(5) manpage).
Thanks again for your suggestion and kind words, i'm really glad my little program could be useful for you :)
Closing this for now. If you have any other questsions, feel free to reopen!
I'm just testing for now but I'm loving it up until now. Got a small problem though : I'm not sure where I should put my custom templates. I need one for .Xresources since using # Start flavours didn't work in it, but I originally created it in
~/.local/share/flavours/base16/templates/xresources/templates
by copying the default one. It worked (i could select it using subtemplate = myfilename in my config.toml, but after a flavours update all, it disappeared. Did I misplace the file ? Or is it unwanted behavior that it god deleted with an update ? If I did misplace it, where would you recomand putting it ? I'd try some things myself, but I'd rather have confirmation before doing all my configurations if there's a risk the files might get deleted later. Thanks for all the work